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>
In-Reply-To: <CAA4eK1LFYdqzQvBF8ygwQn+tJBpNP3ODnx-ArpgOeGuV7F+5OA@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Wed, 18 Feb 2026 16:58:20 +0530
Message-ID: <CAJpy0uDDfqD0giorn7ztk2LQoG4pVp3uoMLuabFPeS-ERjduoA@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/CAJpy0uDDfqD0giorn7ztk2LQoG4pVp3uoMLuabFPeS-ERjduoA%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 18, 2026 at 1:12=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Wed, Feb 18, 2026 at 12:36=E2=80=AFPM shveta malik <shveta.malik@gmail=
.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. In contrast, the apply worker actively consumes the
logical replication stream and is responsible for advancing the slot
and origin. If the apply worker is stopped for an extended period, the
slot cannot advance, which may lead to WAL accumulation on the
publisher. There is no such constraint associated with the seq-sync
worker. And thus stopping the seq-sync worker aggressively (in
scenarios 2 and 3) is both safer and simpler as compared to apply
worker and will also avoid some unnecessary transactions and activity
as I stated above. Thoughts?

thanks
Shveta