]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Handle concurrent sequence refreshes.
authorAmit Kapila <akapila@postgresql.org>
Mon, 20 Jul 2026 05:41:45 +0000 (11:11 +0530)
committerAmit Kapila <akapila@postgresql.org>
Mon, 20 Jul 2026 05:41:45 +0000 (11:11 +0530)
commit45cf7b1e5bf923ca48dfd9aa5001bdd0630d11c3
treee2753d926c88717eb734a827c22cb1dd1819e82d
parent0da71d90d62308d12a789aad8a2a09223976fe88
Handle concurrent sequence refreshes.

'ALTER SUBSCRIPTION ... REFRESH SEQUENCES' can race with a running
sequence synchronization worker. If the worker has fetched a sequence's
value from the publisher but not yet marked it READY, a concurrent refresh
that resets the sequence to INIT can be overwritten by the worker's stale
value, silently losing the refresh request.

Handle this by stopping any running sequence sync worker before resetting
the sequences to INIT. This is race-free because AlterSubscription()
already holds AccessExclusiveLock on the subscription object. That lock
blocks a running worker's UpdateSubscriptionRelState(), which takes
AccessShareLock on the object, and also any worker the apply worker
re-launches, because a new worker takes AccessShareLock on the object in
InitializeLogRepWorker() before it reads pg_subscription_rel. Such a
worker cannot act on the sequence states until the refresh commits, by
which time they are reset to INIT and it will synchronize the latest
publisher values.

Reported-by: Noah Misch <noah@leadboat.com>
Author: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Reviewed-by: Shveta Malik <shveta.malik@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Backpatch-through: 19
Discussion: https://postgr.es/m/20260710045217.f0.noahmisch@microsoft.com
src/backend/commands/subscriptioncmds.c