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>
In-Reply-To: <CAA4eK1L6czEzG4mLNZSyjYC5nX0FMSjjk3csKuxPD3Ph5-7Yvw@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Wed, 18 Feb 2026 12:36:31 +0530
Message-ID: <CAJpy0uAhGQJ=msVsn2GsqWXr+YESJK6x9NBvrUtKvtvp1OVuKQ@mail.gmail.com>
Subject: Re: [PATCH] Support automatic sequence replication
To: Ajin Cherian <itsajin@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>, 
	shveta malik <shveta.malik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAJpy0uAhGQJ%3DmsVsn2GsqWXr%2BYESJK6x9NBvrUtKvtvp1OVuKQ%40mail.gmail.com>
Precedence: bulk

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.

IMO, for scenario 2, we should stop the sequence sync worker. It is of
no use to keep holding one worker slot when there are no publisher
publishing sequences for that subscription.

For scenario 3, it might be acceptable(or may be even expected?) to
keep the seq-sync worker running. But the challenge is how we would
distinguish scenario 2 from scenario 3. I believe scenario 2 will rely
on the absence of sequence entries in pg_subscription_rel to sotp
seq-sync worker. But in both scenario 2 and scenario 3, there would be
no sequence entries in pg_subscription_rel. Given that, to keep the
logic simpler, we can stop the seq-sync worker in scenario 3 as well.
This seems like a corner case, and it should not cause much harm to
stop the worker and restart it later when needed.

Thoughts?

thanks
Shveta