Re: logical decoding and replication of sequences, take 2
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-07-25T13:18:27Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 cited
-
Make test_decoding ddl.out shorter
- d6677b93c79b 17.0 landed
- c5c5832600e9 14.9 landed
- b1dc946eee3d 16.0 landed
- 3bb8b9342f8a 15.4 landed
-
Fix snapshot handling in logicalmsg_decode
- 949ac32e1267 15.3 landed
- 8b9cbd42b61f 14.8 landed
- 4df581fa0f4b 13.11 landed
- 497f863f0598 12.15 landed
- 8de91ebf2ac1 11.20 landed
- 7fe1aa991b62 16.0 landed
-
doc: Adjust a few more references to "postmaster"
- 17e72ec45d31 16.0 cited
-
Revert "Logical decoding of sequences"
- 2c7ea57e56ca 15.0 cited
On Tue, Jul 25, 2023 at 5:29 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > Right. I think the important detail is that during sync we have three > important LSNs > > - LSN1 where the slot is created > - LSN2 where the copy happens > - LSN3 where we consider the sync completed > > For tables, LSN1 == LSN2, because the data is completed using the > snapshot from the temporary slot. And (LSN1 <= LSN3). > > But for sequences, the copy happens after the slot creation, possibly > with (LSN1 < LSN2). And because LSN3 comes from the main subscription > (which may be a bit behind, for whatever reason), it may happen that > > (LSN1 < LSN3 < LSN2) > > The the sync ends at LSN3, but that means all sequence changes between > LSN3 and LSN2 will be applied "again" making the sequence go away. > > IMHO the right fix is to make sure LSN3 >= LSN2 (for sequences). Back in this thread, an approach to use page LSN (LSN2 above) to make sure that no change before LSN2 is applied on subscriber. The approach was discussed in emails around [1] and discarded later for no reason. I think that approach has some merit. [1] https://www.postgresql.org/message-id/flat/21c87ea8-86c9-80d6-bc78-9b95033ca00b%40enterprisedb.com#36bb9c7968b7af577dc080950761290d -- Best Wishes, Ashutosh Bapat