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

On Wed, Feb 18, 2026 at 4:58=E2=80=AFPM shveta malik <shveta.malik@gmail.co=
m> wrote:
>
> On Wed, Feb 18, 2026 at 1:12=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> >
> > On Wed, Feb 18, 2026 at 12:36=E2=80=AFPM shveta malik <shveta.malik@gma=
il.com> wrote:
> > >
> > > I tested a few scenarios on the latest patch. Sequence sync worker di=
d
> > > 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. 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. 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.

--=20
With Regards,
Amit Kapila.