Re: Logical Replication of sequences
shveta malik <shveta.malik@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Add documentation for sequence synchronization.
- 55cefadde874 19 (unreleased) landed
-
Remove unused assignment in CREATE PUBLICATION grammar.
- bfb7419b0bbe 19 (unreleased) landed
-
Add seq_sync_error_count to subscription statistics.
- f6a4c498dcf6 19 (unreleased) landed
-
Fix few issues in commit 5509055d69.
- 5a4eba558aa7 19 (unreleased) landed
-
Add sequence synchronization for logical replication.
- 5509055d6956 19 (unreleased) landed
-
Add worker type argument to logical replication worker functions.
- 3e8e05596a02 19 (unreleased) landed
-
Introduce "REFRESH SEQUENCES" for subscriptions.
- f0b3573c3aac 19 (unreleased) landed
-
Refactor logical worker synchronization code into a separate file.
- 41c674d2e31e 19 (unreleased) landed
-
Standardize use of REFRESH PUBLICATION in code and messages.
- 2436b8c047ff 19 (unreleased) landed
-
Add "ALL SEQUENCES" support to publications.
- 96b378497346 19 (unreleased) landed
-
Expose sequence page LSN via pg_get_sequence_data.
- b93172ca59f4 19 (unreleased) landed
-
Resume conflict-relevant data retention automatically.
- 0d48d393d465 19 (unreleased) cited
-
Post-commit review fixes for 228c370868.
- 1f7e9ba3ac4e 19 (unreleased) cited
-
Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
On Fri, Nov 7, 2025 at 10:58 AM vignesh C <vignesh21@gmail.com> wrote:
>
>
> Thanks for pushing the patch, here is a rebased version of the
> remaining patches.
>
Please find a few comments on doc patch:
1)
+ them. To verify this, compare the
+ <link linkend="catalog-pg-subscription-rel">pg_subscription_rel</link>.<structfield>srsublsn</structfield>
+ on the subscriber with the page_lsn obtained from the
+ <function>pg_get_sequence_data</function> for the sequence on the
publisher.
Is there a way to give link of 'pg_get_sequence_data' here?
2)
+ <warning>
+ <para>
+ Each sequence caches a block of values (typically 32) in memory before
+ generating a new WAL record, so its LSN advances only after the entire
+ cached batch has been consumed. As a result, sequence value
drift cannot be
+ detected by comparing LSNs for sequence increments that fall within the
+ same cached block.
+ </para>
+ </warning>
In such a case, shall we mention that compare last_value to see the
drift? Thoughts?
3)
+ To detect this, compare the
+ <link linkend="catalog-pg-subscription-rel">pg_subscription_rel</link>.<structfield>srsublsn</structfield>
+ on the subscriber with the page_lsn obtained from the
+ <function>pg_get_sequence_data</function> for the sequence on the
publisher.
We have mentioned above. But in the example of the same, we do not
show srsublsn or page_lsn anywhere. Shall we query and show that as
well?
4)
Maximum number of synchronization workers per subscription. This
parameter controls the amount of parallelism of the initial data copy
during the subscription initialization or when new tables are added.
+ One additional worker is also needed for sequence synchronization.
</para>
Since now the first line is talking only about table-sync, shall we tweak it:
'of the initial data copy' --> 'of the initial data copy for tables'
5)
+ Returns information about the sequence. <literal>last_value</literal>
+ indicates last sequence value set in sequence by nextval or setval,
last_value can also be set by seq synchronization. Do you think that
we need to mention that or current info is good enough?
thanks
Shveta