Re: logical decoding and replication of sequences, take 2
От | Ashutosh Bapat |
---|---|
Тема | Re: logical decoding and replication of sequences, take 2 |
Дата | |
Msg-id | CAExHW5uCUSNTn421eH5d2pVDh-DM=SJ3sERsKu-aQrP6ZPh08g@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
|
Список | pgsql-hackers |
On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > Anyway, I was thinking about this a bit more, and it seems it's not as > difficult to use the page LSN to ensure sequences don't go backwards. > The 0005 change does that, by: > > 1) adding pg_sequence_state, that returns both the sequence state and > the page LSN > > 2) copy_sequence returns the page LSN > > 3) tablesync then sets this LSN as origin_startpos (which for tables is > just the LSN of the replication slot) > > AFAICS this makes it work - we start decoding at the page LSN, so that > we skip the increments that could lead to the sequence going backwards. > I like this design very much. It makes things simpler than complex. Thanks for doing this. I am wondering whether we could reuse pg_sequence_last_value() instead of adding a new function. But the name of the function doesn't leave much space for expanding its functionality. So we are good with a new one. Probably some code deduplication. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: