Re: Logical Replication of sequences

shveta malik <shveta.malik@gmail.com>

From: shveta malik <shveta.malik@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Shinya Kato <shinya11.kato@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Dilip Kumar <dilipbalaut@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, "Jonathan S. Katz" <jkatz@postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2025-11-07T09:23:55Z
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 →
  1. Doc: Add documentation for sequence synchronization.

  2. Remove unused assignment in CREATE PUBLICATION grammar.

  3. Add seq_sync_error_count to subscription statistics.

  4. Fix few issues in commit 5509055d69.

  5. Add sequence synchronization for logical replication.

  6. Add worker type argument to logical replication worker functions.

  7. Introduce "REFRESH SEQUENCES" for subscriptions.

  8. Refactor logical worker synchronization code into a separate file.

  9. Standardize use of REFRESH PUBLICATION in code and messages.

  10. Add "ALL SEQUENCES" support to publications.

  11. Expose sequence page LSN via pg_get_sequence_data.

  12. Resume conflict-relevant data retention automatically.

  13. Post-commit review fixes for 228c370868.

  14. Generate GUC tables from .dat file

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