Horton

Re: Logical Replication of sequences

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Peter Smith <smithpb2250@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-27T11:40:19Z
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 27, 2025 at 12:19 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Mon, 27 Oct 2025 at 10:04, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Mon, Oct 27, 2025 at 8:23 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> >>
> >> On Friday, October 24, 2025 11:22 PM vignesh C <vignesh21@gmail.com> wrote:
> >> >
> >> > On Thu, 23 Oct 2025 at 16:47, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> > >
> >> > > On Thu, Oct 23, 2025 at 11:45 AM vignesh C <vignesh21@gmail.com> wrote:
> >> > > >
> >> > > > The attached patch has the changes for the same.
> >> > > >
> >> > >
> >> > > I have pushed 0001 and the following are comments on 0002.
> >> >
> >
> >
> > One question, I am not sure if this has been discussed before, So while getting sequence information from remote we are also getting the page_lsn of the sequence and we are storing that in pg_subscription_rel.  Is it just for the user to see and compare whether the sequence is synced to the latest lsn or is it used for anything else as well?  In our patch sert, I don't see much usability information about this field.
>
> This is mainly intended for the following purposes:  a) To determine
> whether the sequence requires resynchronization by comparing it with
> the latest LSN on the publisher b. ) To maintain consistency with
> table synchronization behavior.  c) To inform users up to which LSN
> the sequence has been synchronized.
> Further details will be documented in an upcoming patch.
>

Can we use it to build an auto-sequence-sync feature? One can imagine
that at some threshold interval apply_worker can check if any of the
replicated sequences are out-of-sync and if so, then sync those. We
can do this before the apply_worker waits for some activity or on a
clean shutdown. That way users won't need to manually sync these
sequences before upgrade.

-- 
With Regards,
Amit Kapila.