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
