MIME-Version: 1.0
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>
In-Reply-To: <CAA4eK1JiWtfDNu4kBsFyck_2pg+DW30V6u1=j6F0ctyvWAa84Q@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Thu, 19 Feb 2026 09:49:34 +0530
Message-ID: <CAJpy0uDk=NRS=neyyDXfSzbBMeAHf_Sgy_UGeA1BscyEyaVWSQ@mail.gmail.com>
Subject: Re: [PATCH] Support automatic sequence replication
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAJpy0uDk%3DNRS%3DneyyDXfSzbBMeAHf_Sgy_UGeA1BscyEyaVWSQ%40mail.gmail.com>
Precedence: bulk

On Thu, Feb 19, 2026 at 7:45=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Wed, Feb 18, 2026 at 4:58=E2=80=AFPM shveta malik <shveta.malik@gmail.=
com> wrote:
> >
> > On Wed, Feb 18, 2026 at 1:12=E2=80=AFPM Amit Kapila <amit.kapila16@gmai=
l.com> wrote:
> > >
> > > On Wed, Feb 18, 2026 at 12:36=E2=80=AFPM shveta malik <shveta.malik@g=
mail.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 publicati=
on?
> > >
> >
> > 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=E2=80=99t 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=E2=80=99t need any
extra awareness in the apply worker. Given that, I don=E2=80=99t 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