On Tue, 3 Feb 2026 at 15:52, shveta malik <[email protected]> wrote: > > 3) > If a sequence sync worker is taking a nap, and subscription is > disabled or the server is stopped just before upgrade, how is the user > supposed to know that sequences are synced at the end?
One way to address the upgrade issue is to record the publisher LSN at the completion of the most recent SEQUENCE SYNC and persist it in the subscription metadata. During an upgrade, the following check should be performed: If the last recorded sequence-sync LSN is not ahead of the apply worker's LSN, report a clear error instructing the user to disable the subscription and explicitly run: ALTER SUBSCRIPTION … REFRESH SEQUENCES. Additionally, the existing ALTER SUBSCRIPTION … REFRESH SEQUENCES command should be enhanced so that it can be executed on disabled subscriptions and perform sequence synchronization independently, without relying on the sequence sync worker. Supporting execution on a disabled subscription is necessary because, if REFRESH SEQUENCES is run while the subscription is enabled, the apply worker may start immediately, ingest new transactions, and advance the replication slot's LSN beyond the point at which sequences were last synchronized again. Note: This approach may conservatively report that sequences need to be synchronized even when no sequence values have actually changed. This limitation is inherent to the design, as during an upgrade we don't connect to the publisher and decode WAL between the two LSNs to determine whether any sequence changes actually occurred. Regards, Vignesh
