From cec0a51f91175343525900b6b8c0985f0b3e3385 Mon Sep 17 00:00:00 2001 From: Ajin Cherian Date: Mon, 14 Jul 2025 06:04:38 -0400 Subject: [PATCH v2] Fix a possible deadlock during ALTER SUBSCRIPTION ... DROP PUBLICATION In most situations the tablesync worker will drop the corresponding origin before it finishes executing, but if an error causes the tablesync worker to fail just prior to dropping the origin, or if it is delayed or it didn't get cpu time, the apply worker could find the origin and attempt to drop the origin. During this time if the user simultaneously issues an ALTER SUBSCRIPTION ... DROP PUBLICATION, there is a possibility of a deadlock between the apply worker and the user process, because of the order in which the locks are taken. The ALTER SUBSCRIPTION code takes a AccessExclusiveLock on SubscriptionRelationId initially and now the fix is for the apply worker to also take an AccessShareLock on SubscriptionRelationId prior to dropping any origins. --- src/backend/replication/logical/tablesync.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/backend/replication/logical/tablesync.c b/src/backend/replication/logical/tablesync.c index e4fd634..c410bde 100644 --- a/src/backend/replication/logical/tablesync.c +++ b/src/backend/replication/logical/tablesync.c @@ -492,7 +492,13 @@ process_syncing_tables_for_apply(XLogRecPtr current_lsn) * worker to remove the origin tracking as if there is any * error while dropping we won't restart it to drop the * origin. So passing missing_ok = true. + * + * Also lock SubscriptionRelationId with AccessShareLock to + * prevent any deadlocks with the user concurrently performing + * refresh on the subscription. */ + LockSharedObject(SubscriptionRelationId, MyLogicalRepWorker->subid, + 0, AccessShareLock); ReplicationOriginNameForLogicalRep(MyLogicalRepWorker->subid, rstate->relid, originname, -- 1.8.3.1