Horton

Re: Logical Replication of sequences

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, shveta malik <shveta.malik@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Shlok Kyal <shlok.kyal.oss@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-09-05T09:16:20Z
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, 5 Sept 2025 at 04:01, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Aug 20, 2025 at 4:57 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Aug 18, 2025 at 3:36 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > Thanks for the comments, the updated version has the changes for the same.
> > >
> >
> > I wanted to first discuss a few design points. The patch implements
> > "ALTER SUBSCRIPTION ... REFRESH PUBLICATION SEQUENCES" such that it
> > copies the existing sequences values and also adds/removes any missing
> > sequences. For the second part (add/remove sequences), we already have
> > a separate command "ALTER SUBSCRIPTION ... REFRESH PUBLICATION". So, I
> > feel the new command should only copy the sequence values, as that
> > will keep the interface easy to define and understand. Additionally,
> > it will help to simplify the code in the patch, especially in the
> > function AlterSubscription_refresh.
>
> While I agree that the new command just copies the sequence values,
> I'm not sure the command should be implemented as an extension of
> ALTER SUBSCRIPTION ... REFRESH PUBLICATION command. Probably what the
> new command does is quite different from what REFRESH PUBLICATION
> command does?

Alternatively, the syntax options could be:
ALTER SUBSCRIPTION subname RESYNC PUBLICATION SEQUENCES;
or
ALTER SUBSCRIPTION subname RESYNC SEQUENCES;

Do you have a preference between the two?

> >
> > We previously discussed *not* to launch an apply worker if the
> > corresponding publication(s) only publish sequences. See [1]. We
> > should consider it again to see if that is a good idea. It will have
> > some drawbacks as compared to the current approach of doing sync via
> > sync worker. The command could take time for a large number of
> > sequences, and on failure, retry won't happen which can happen with
> > background workers. Additionally, when the connect option is false for
> > a subscription during creation, the user needs to later call REFRESH
> > to sync the sequences after enabling the subscription. OTOH, doing the
> > sync during the command will bring more predictability and simplify
> > the patch. What do others think?
>
> It seems okay to me that we launch an apply worker for a subscription
> corresponding to sequence-only publications. I think the situation
> seems somewhat similar to the case where we launch an apply worker
> even for a subscription corresponding to empty publications. It would
> be quite a rare case in practice where publications have only
> sequences.

I agree with this.

> I guess that it would rather simplify the patch if we can
> cut the part of doing the sync during the command (i.e., not
> distinguish between table-and-sequence publications and sequence-only
> publications), no?

Currently, we don’t make a distinction between the two. Just to
clarify, could you point me to the specific part of the patch you’re
referring to?

Regards,
Vignesh