Re: logical decoding and replication of sequences, take 2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: logical decoding and replication of sequences, take 2
Date
Msg-id CA+Tgmoaxertx9iuSeGOoocvq=5GTgZyXZvZBf4w24mQpyz7LRA@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding and replication of sequences, take 2  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: logical decoding and replication of sequences, take 2
List pgsql-hackers
On Wed, Feb 14, 2024 at 10:21 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> The way I think about non-transactional sequence changes is as if they
> were tiny transactions that happen "fully" (including commit) at the LSN
> where the LSN change is logged.

100% this.

> It does not mean we can arbitrarily reorder the changes, it only means
> the changes are applied as if they were independent transactions (but in
> the same order as they were executed originally). Both with respect to
> the other non-transactional changes, and to "commits" of other stuff.

Right, this is very important and I agree completely.

I'm feeling more confident about this now that I heard you say that
stuff -- this is really the key issue I've been worried about since I
first looked at this, and I wasn't sure that you were in agreement,
but it sounds like you are. I think we should (a) fix the locking bug
I found (but that can be independent of this patch) and (b) make sure
that this patch documents the points from the quoted material above so
that everyone who reads the code (and maybe tries to enhance it) is
clear on what the assumptions are.

(I haven't checked whether it documents that stuff or not. I'm just
saying it should, because I think it's a subtlety that someone might
miss.)

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Memory consumed by paths during partitionwise join planning
Next
From: Michael Paquier
Date:
Subject: Re: 039_end_of_wal: error in "xl_tot_len zero" test