Horton

Re: Logical Replication of sequences

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2025-10-07T08:51:13Z
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 Mon, Oct 6, 2025 at 4:33 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Mon, 6 Oct 2025 at 12:07, vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Sat, 4 Oct 2025 at 21:24, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Tue, Sep 30, 2025 at 9:55 PM vignesh C <vignesh21@gmail.com> wrote:
> > > >
> > >
> > > In the 0001 patch, pg_get_sequence_data() exposes two new fields
> > > log_cnt and page_lsn. I see that the later subscriber-side patch uses
> > > both, the first one in SetSequence(). It is not clear from the
> > > comments or the commit message of 0001 why it is necessary to use
> > > log_cnt when setting the sequence. Can you explain what the problem
> > > will be if we don't use log_cnt during sequence sync?
> >
> > I thought to keep the log_cnt value the same value as the publisher.
> > I have verified from the upgrade that we don't retain the log_cnt
> > value after upgrade, even if we copy log_cnt, the value will not be
> > retained. The attached
> > v20251006-0001-Enhance-pg_get_sequence_data-function.patch has the
> > changes to remove log_cnt.
>
> Here is the rebased remaining patches.

While testing the patches with different combinations to make
publications, I do not understand why we don't support ALL SEQUENCE
with some table option, or is it future pending work.

postgres[1390699]=# CREATE PUBLICATION pub FOR ALL SEQUENCES, table test;
ERROR:  42601: syntax error at or near "table"
LINE 1: CREATE PUBLICATION pub FOR ALL SEQUENCES, table test;
LOCATION:  scanner_yyerror, scan.l:1236


postgres[1390699]=# CREATE PUBLICATION pub FOR table test, ALL SEQUENCES;
ERROR:  42601: syntax error at or near "all"
LINE 1: CREATE PUBLICATION pub FOR table test, all sequences;

I am doing more review/test from a usability perspective, but thought
of asking this, while I am reviewing further.

-- 
Regards,
Dilip Kumar
Google