On Fri, Feb 6, 2026 at 6:07 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Tue, 3 Feb 2026 at 15:52, shveta malik <shveta.malik@gmail.com> 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.
I guess here we are trying to target the problem where a table is
dependent upon sequence and table data is replicated while seq's is
not. And post upgrade, say if somehow the same sequence is used on the
subscriber to insert data in the table, values can go back.
> 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.
>
I like the idea. In particular, I like the approach of providing a
REFRESH SEQUENCE command to the user. Even if we don’t implement the
check during the upgrade process, we can clearly document that users
should verify sequence drift before upgrading. If any sequence drift
is detected, they should run REFRESH-SEQ manually.
thanks
Shveta
