Re: [PATCH] Support automatic sequence replication
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-20T06:24:22Z
Lists: pgsql-hackers
On Fri, Feb 20, 2026 at 10:48 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Feb 20, 2026 at 10:11 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Tue, Feb 3, 2026 at 9:18 AM Ajin Cherian <itsajin@gmail.com> wrote: > > > > > > Hello hackers, > > > > > > I'd like to propose an improvement to the sequence replication feature > > > that was committed in [1]. > > > > > > The current implementation synchronizes sequences during initial > > > subscription setup, but the sequence sync worker exits after this > > > initial sync. This means that as sequences advance on the publisher, > > > they drift from the subscriber values over time. Users must manually > > > run ALTER SUBSCRIPTION ... REFRESH SEQUENCES to resynchronize, which > > > requires monitoring and intervention. > > > > Thanks, Ajin, for the proposal. I am trying to think: what is the use > > case for automatically updating the sequence values? IIUC, the only > > use case for the sequence sync worker was when using logical > > replication for an upgrade; after the upgrade, you should have > > up-to-date values for the sequences. By adding an automatic update, > > are you targeting any new use case? > > > > If we are still targeting the same use case, I’d like to understand > > how updating the value at specific intervals will improve the user > > experience. > > > > Even for an upgrade, to avoid large downtime, it would be better if > the subscriber has the latest values of sequences, so that during the > upgrade of the publisher, the subscriber can receive all client > requests. It is possible with the REFRESH SEQUENCES command as well > but in the worst case (when there are large number of sequences), it > can take much longer time. To clarify, here is the specific sequence synchronization use case I have in mind (major version upgrade with minimal downtime ) Setup: A PUB-SUB environment, both on PG17. Goal: Upgrade to PG18 with near-zero downtime. Upgrade: Run pg_upgrade on the Subscriber to move it to PG18. Replication: Logical replication continues from the PG17 Publisher to the PG18 Subscriber, including sequences. Sync: Wait for replication lag to hit near-zero and synchronize sequences. Cutover: Stop all traffic on the Publisher. Final Catch-up: Allow the PG18 Subscriber to catch up and perform a final sequence refresh. Switchover: Redirect all traffic to the Subscriber. In this major version upgrade scenario, the downtime is minimal (only while waiting for Final Catch-up). However, before the final switchover, the user must ensure all data and sequences are fully synced. They usually can't afford to wait for an automatic background sync, they need to force it using REFRESH SEQUENCES. My question is, does the proposed automatic sync allow us to avoid manual refreshes entirely in this process? Or is there another use case where the advantages of automation are more apparent? -- Regards, Dilip Kumar Google
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