Horton

Re: Logical Replication of sequences

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: shveta malik <shveta.malik@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>
Date: 2025-11-07T14:47:57Z
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

Attachments

On Fri, 7 Nov 2025 at 14:54, shveta malik <shveta.malik@gmail.com> wrote:
>
> 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?

Modified

> 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?

I was not sure as it might not be very efficient

> 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?

Updated example

>
> 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'

Modified

> 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?

Updated

The attached v20251107_2 version patch has the changes for the same.

Regards,
Vignesh