Re: Logical Replication of sequences

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: vignesh C <vignesh21@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>, shveta malik <shveta.malik@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Chao Li <li.evan.chao@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-10-22T05:37:10Z
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 Wed, Oct 22, 2025 at 10:53 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi Vignesh,
>
> Here are a few review comments for patch 0001:
>
> ======
> src/backend/catalog/pg_subscription.c
>
> GetSubscriptionRelations:
>
> 1.
>  List *
> -GetSubscriptionRelations(Oid subid, bool not_ready)
> +GetSubscriptionRelations(Oid subid, bool otherwise return all the
> relations of the subscription, bool get_sequences,
> + bool not_ready)
>
> Now the function parameter means the (unchanged) function comment is
> not correct anymore.
>
> e.g. It still says "otherwise return all the relations of the
> subscription", but that does not account for the parameters indicating
> if you only want tables, or only want sequences.
>

I think the code for those parameters is quite clear. The previous
version had few comments but I found those unnecessary.

> src/backend/replication/logical/syncutils.c
>
> 10.
> bool
> FetchRelationStates(bool *started_tx)
>
> IIUC, you are using the terminology "relations" to apply to both
> tables or sequences; OTOH ", tables" is just tables. It seems this
> function is table-specific. Should it have a name change like
> FetchTableStates?
>

The patch 0002 has some changes related to sequences in this function.
So, I think the current naming is okay.

> ======
> src/test/subscription/t/036_sequences.pl
>
> 11.
> There are no test cases checking that ALTER commands will correctly
> add/remove sequences in the pg_subscription_rel?
>

The patch 0002 has tests related to ALTER commands. I don't think 0001
needs tests for all kinds of statements as both will be committed a
few days apart.

-- 
With Regards,
Amit Kapila.