Re: [PATCH] Support automatic sequence replication

On Thu, Feb 19, 2026 at 7:45 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Feb 18, 2026 at 4:58 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Wed, Feb 18, 2026 at 1:12 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Feb 18, 2026 at 12:36 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > > >
> > > > I tested a few scenarios on the latest patch. Sequence sync worker did
> > > > not stop in below scenarios:
> > > >
> > > > 1) When the subscription was disabled.
> > > > 2) When the only publication for sequences was dropped from
> > > > subscription ( ALTER SUBSCRIPTION sub1 DROP PUBLICATION pub_seq;)
> > > > 3) When all sequences were dropped on sub.
> > > >
> > > > Application worker stops in scenario 1, seq-sync worker should also
> > > > stop. See maybe_reread_subscription().
> > > >
> > > > We need to decide the behavior of the seq-sync worker for 2 and 3.
> > > >
> > >
> > > Shouldn't we try to map (2) and (3) to what we do for table publication?
> > >
> >
> > I thought about it, this is what I have in mind:
> >
> > 1) When there is no sequences and tables to be synced, we will be
> > blocking 2 workers slot, one for apply worker and one for seq-sync
> > worker. While only apply-worker is enough, as it may restart seq-sync
> > worker as soon as it notices a sequence.
> >
> > 2) In case of apply-worker, when no tables are being published, it
> > hardly does any work. IIUC, it just sends responses to keep-alive
> > messages. OTOH, seq-sync worker will begin a transaction and query
> > pg_subscription_rel every few seconds. I feel, we should avoid this
> > unnecessary activity if possible.
> >
> > Overall, I feel the sequence sync worker is logically different from
> > the table apply worker. It behaves more like an auxiliary worker
> > managed by the apply worker and derives all of its state from the
> > system catalogs.
> >
>
> I understand that sequence-sync worker won't be doing anything useful
> in such corner cases but the chances of such situations are rare and
> the consequences are not that bad. Similarly, one can say that we can
> exit the launcher process when no subscription is present and the
> system should figure out and restart when required.

No, I don’t think this is comparable to our case. For that scenario to
work, we would need to expose subscription-related awareness and state
to the postmaster, which is not recommended. In our case, the apply
worker is already responsible for monitoring the sequence-sync worker.
It is already checking two things:
--whether the subscription includes sequences, and
--whether the sequence-sync worker is running and if not, it starts it.

So there is no additional logic required. None. We don’t need any
extra awareness in the apply worker. Given that, I don’t think the two
cases are comparable at all.

But I also agree that it is a corner case, and running additional
seq-sync worker per subscription may not harm that much.

> In this case also,
> the apply-worker needs to check from time-to-time or needs to be
> informed to launch the new sequence-sync worker.

It is already doing that. There is always a case where seq-sync worker
errors out or exits unexpectedly. In such a case, the apply worker is
the one to start it again. And for that, apply worker has to keep
checking it.

> I think we can
> evaluate these cases separately and can decide to write a top-up patch
> if found useful to make sequence-sync worker detect and exit.
>

Sure, we can do that.

thanks
Shveta