Re: [PATCH] Support automatic sequence replication
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
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>
Date: 2026-02-18T11:28:20Z
Lists: pgsql-hackers
On Wed, Feb 18, 2026 at 1:12 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Feb 18, 2026 at 12:36 PM 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't include wait_event.h in pgstat.h
- 868825aaeb40 19 (unreleased) cited
-
Don't include proc.h in shm_mq.h
- a2c89835f512 19 (unreleased) cited
-
Fix unsafe RTE_GROUP removal in simplify_EXISTS_query
- 77c7a17a6e5f 19 (unreleased) cited
-
Add sequence synchronization for logical replication.
- 5509055d6956 19 (unreleased) cited