RE: Logical Replication of sequences

On Thursday, October 16, 2025 5:59 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> 
> On Wed, Oct 15, 2025 at 4:51 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > Here is the new version patch set which includes the following changes:
> >
> 
> I have pushed the first patch. Kindly rebase and share the remaining patches.

Thanks! Here is the remaining patches, which addressed all pending comments.

Regarding whether we can avoid creating slot/origin for seq-only publication.
I think the main challenge lies in ensuring the apply worker operates smoothly
without a replication slot. Currently, the apply worker uses the
START_REPLICATION command with a replication slot to acquire the slot on the
publisher. To bypass this, it's essential to skip starting the replication and
specifically, avoid entering the LogicalRepApplyLoop().

To address this, I thought to implement a separate loop dedicated to
sequence-only subscriptions. Within this loop, the apply worker would only call
functions like ProcessSyncingSequencesForApply() to manage sequence
synchronization while periodically checking for any new tables added to the
subscription. If new tables are detected, the apply worker would exit this loop
and enter the LogicalRepApplyLoop().

I chose not to consider allowing the START_REPLICATION command to operate
without a logical slot, as it seems like an unconventional approach requiring
modifications in walsender and to skip logical decoding and related processes.

Another consideration is whether to address scenarios where tables are
subsequently removed from the subscription, given that slots and origins would
already have been created in such cases.

Since it might introduce addition complexity to the patches, and considering
that we already allow slot/origin to be created for empty subscription, it might
also be acceptable to allow it to be created for sequence-only subscription. So,
I chose to add some comments to explain the reason for it in latest version.

Origin case might be slightly easier to handle, but it could also require some
amount of implementations. Since origin is less harmful than a replication slot
and maintaining it does not have noticeable overhead, it seems OK to me to
retain the current behaviour and add some comments in the patch to clarify the
same.

Best Regards,
Hou zj