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
