RE: Logical Replication of sequences

On Saturday, October 18, 2025 3:44 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Oct 17, 2025 at 1:35 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Fri, Oct 17, 2025 at 10:01 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> > >
> > > On Thu, Oct 16, 2025 at 4:53 PM Zhijie Hou (Fujitsu)
> > > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > I agree that avoiding to create a slot/origin for sequence-only
> > > subscription is not worth the additional complexity at other places,
> > > especially when we do create them for empty subscriptions.
> >
> > +1.
> >
> > While testeing 001 patch alone, I found that for sequence-only
> > subscription, we get error in tablesync worker :
> > ERROR: relation "public.seq1" type mismatch: source "table", target
> "sequence"
> >
> > This error comes because during copy_table(),
> > logicalrep_relmap_update() does not update relkind and thus later
> > CheckSubscriptionRelkind() ends up giving the above error.

Fixed in latest version.

>
> I faced the same error while reviewing the 0001 patch. I think if we're going to
> push these patches separately the 0001 patch should have at least minimal
> regression tests. Otherwise, I'm concerned that buildfarm animals won't
> complain but we could end up blocking other logical replication developments.

I moved some test from 0002 to 0001. Thanks Kuroda-San for contributing
codes for this change.

Best Regards,
Hou zj