Re: [PATCH] Support automatic sequence replication

public inbox for [email protected]  
help / color / mirror / Atom feed

From: shveta malik <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: [PATCH] Support automatic sequence replication
Date: Thu, 19 Feb 2026 09:49:34 +0530
Message-ID: <CAJpy0uDk=NRS=neyyDXfSzbBMeAHf_Sgy_UGeA1BscyEyaVWSQ@mail.gmail.com> (raw)
In-Reply-To: <CAA4eK1JiWtfDNu4kBsFyck_2pg+DW30V6u1=j6F0ctyvWAa84Q@mail.gmail.com>
References: <CAFPTHDZXX9WQ_X1ZfEvS248T+pKuk6SmCnXcvgPM059N1xPUfA@mail.gmail.com>
	<CAJpy0uDLUEjHHME8om1vAf6qkXCeRR6cBvkpK8yWBAC=T0ZFLA@mail.gmail.com>
	<CAFPTHDZg1JrunGgOj332hr+gUuH_Jm7skqPpYSvd-QE3yEdRDQ@mail.gmail.com>
	<CAJpy0uBz7MCSUkvFJD9ij65vBahNmY+bfCgdGKRqXovYs+K_TA@mail.gmail.com>
	<CAJpy0uDsuNqjWd-TmGBxqSS1rnVCJ3B8=SYrtxQ=Vs8kb71QFA@mail.gmail.com>
	<CAJpy0uAMWg3KcXtVBS7B0rnchLNrCCVYBByJCzAp=u5LERgtfA@mail.gmail.com>
	<CAFPTHDZwEhxhDAeqcPi0GuYN6xBs8gFXHOMUnbg3u2Xigcz4Zg@mail.gmail.com>
	<CAE9k0PmTyCU1A9YEf+MRgfeZ8yK1bAYJu=o0bH8DNUTzXejQyQ@mail.gmail.com>
	<CAA4eK1L6czEzG4mLNZSyjYC5nX0FMSjjk3csKuxPD3Ph5-7Yvw@mail.gmail.com>
	<CAJpy0uAhGQJ=msVsn2GsqWXr+YESJK6x9NBvrUtKvtvp1OVuKQ@mail.gmail.com>
	<CAA4eK1LFYdqzQvBF8ygwQn+tJBpNP3ODnx-ArpgOeGuV7F+5OA@mail.gmail.com>
	<CAJpy0uDDfqD0giorn7ztk2LQoG4pVp3uoMLuabFPeS-ERjduoA@mail.gmail.com>
	<CAA4eK1JiWtfDNu4kBsFyck_2pg+DW30V6u1=j6F0ctyvWAa84Q@mail.gmail.com>

On Thu, Feb 19, 2026 at 7:45 AM Amit Kapila <[email protected]> wrote:
>
> On Wed, Feb 18, 2026 at 4:58 PM shveta malik <[email protected]> wrote:
> >
> > On Wed, Feb 18, 2026 at 1:12 PM Amit Kapila <[email protected]> wrote:
> > >
> > > On Wed, Feb 18, 2026 at 12:36 PM shveta malik <[email protected]> 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

view thread (58+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Support automatic sequence replication
  In-Reply-To: <CAJpy0uDk=NRS=neyyDXfSzbBMeAHf_Sgy_UGeA1BscyEyaVWSQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox