database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Revert "Reject concurrent sequence refreshes".

Browse Source 
This reverts commit f38afa4abb.

That commit fixed a race that could leave stale sequence values on the
subscriber after 'ALTER SUBSCRIPTION ... REFRESH SEQUENCES'. It did so by
raising an ERROR during 'ALTER SUBSCRIPTION ... REFRESH SEQUENCES'
whenever a sequence synchronization worker was already running for the
subscription.

That approach caused intermittent buildfarm failures, because the existing
tests did not ensure the sequencesync worker had stopped before executing
'ALTER SUBSCRIPTION ... REFRESH SEQUENCES'. While discussing how to fix
the tests, we concluded that blocking the command while a sequencesync
worker is running is inconvenient for users. So we will fix the original
race differently in a follow-up commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Amit Kapila <amit.kapila16@gmail.com>
Backpatch-through: 19
Discussion: https://postgr.es/m/3614163.1784163070@sss.pgh.pa.us
Discussion: https://postgr.es/m/20260710045217.f0.noahmisch@microsoft.com
This commit is contained in:
Amit Kapila
2026-07-18 07:53:13 +05:30
parent 5ed9cee74c
commit fd27c7e64f
2 changed files with 0 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
src/backend/commands/subscriptioncmds.c
View File

@@ -1304,33 +1304,6 @@ AlterSubscription_refresh_seq(Subscription *sub)
WalReceiverConn *wrconn;
bool must_use_password;
/*
* Disallow a concurrent REFRESH SEQUENCES while a sequence sync worker
* for this subscription is still running. This avoids a race where the
* publisher's sequence advances after the current worker has fetched its
* value but before it marks the sequence READY. A user may then issue
* another REFRESH SEQUENCES to synchronize the updated value. Since the
* affected sequences are already in the INIT state, the running worker
* has no indication that a new synchronization has been requested. It
* would then apply the stale value it already fetched and mark the
* sequence READY, causing the new synchronization request to be lost and
* preventing the updated publisher values from being synchronized.
*/
LWLockAcquire(LogicalRepWorkerLock, LW_SHARED);
if (logicalrep_worker_find(WORKERTYPE_SEQUENCESYNC, sub->oid, InvalidOid,
true))
{
LWLockRelease(LogicalRepWorkerLock);
ereport(ERROR,
errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
/* translator: %s is an SQL ALTER command */
errmsg("cannot execute %s while a sequence synchronization worker is running",
"ALTER SUBSCRIPTION ... REFRESH SEQUENCES"),
errhint("Try again after the current synchronization completes."));
}
LWLockRelease(LogicalRepWorkerLock);
/* Load the library providing us libpq calls. */
load_file("libpqwalreceiver", false);

4
src/test/subscription/t/036_sequences.pl
View File

@@ -286,10 +286,6 @@ $node_publisher->safe_psql(
CREATE SEQUENCE regress_s4 START 10 INCREMENT 2;
));
# Wait for the missing sequence added to be synced
$node_subscriber->poll_query_until('postgres', $synced_query)
or die "Timed out while waiting for subscriber to synchronize data";
##########
# Ensure that insufficient privileges on the publisher for a sequence
# are reported correctly as a permission issue, not as a missing sequence.