On Wed, Feb 11, 2026 at 9:21 AM shveta malik <[email protected]> wrote: > > > 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. >
Yeah, implementing such checks are not required in upgrade but it is better to document the use of this command in upgrade context. -- With Regards, Amit Kapila.
