Re: Logical Replication of sequences - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Logical Replication of sequences
Date
Msg-id CAD21AoBdYLJBZz0Tvp1qi2NaPEV6drp97haDkxVsNZndhPy3=w@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication of sequences  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Logical Replication of sequences
List pgsql-hackers
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?

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

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Josh Curtis
Date:
Subject: Fix race condition in SSI when reading PredXact->SxactGlobalXmin
Next
From: Rishu Bagga
Date:
Subject: Re: Proposal: Out-of-Order NOTIFY via GUC to Improve LISTEN/NOTIFY Throughput