Re: logical decoding and replication of sequences, take 2

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical decoding and replication of sequences, take 2
Дата
Msg-id CA+Tgmoaxertx9iuSeGOoocvq=5GTgZyXZvZBf4w24mQpyz7LRA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical decoding and replication of sequences, take 2  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: logical decoding and replication of sequences, take 2  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrei Lepikhov
Дата:
Сообщение: Re: Memory consumed by paths during partitionwise join planning
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: 039_end_of_wal: error in "xl_tot_len zero" test