From 5bee6b435a89a3d313137472c6d7d30ff818925b Mon Sep 17 00:00:00 2001 From: Ajin Cherian Date: Tue, 8 Jul 2025 06:18:23 -0400 Subject: [PATCH] Fix a deadlock during ALTER SUBSCRIPTION ... DROP PUBLICATION When user drops a publication from a subscription, this will result in a publication refresh on the subscriber which will try and drop any pending origins. Meanwhile the apply worker could also be trying to cleanup origins. There could be a deadlock if the order of locking of SubscriptionRelationId, SubscriptionRelRelationId and ReplicationOriginRelationId are not aligned between functions process_syncing_tables_for_apply() and AlterSubscription_refresh(). The fix is to get an AccessShareLock on SubscriptionRelationId in process_syncing_tables_for_apply() in advance. --- src/backend/replication/logical/tablesync.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/backend/replication/logical/tablesync.c b/src/backend/replication/logical/tablesync.c index e6159ac..4fd0bb3 100644 --- a/src/backend/replication/logical/tablesync.c +++ b/src/backend/replication/logical/tablesync.c @@ -470,7 +470,14 @@ process_syncing_tables_for_apply(XLogRecPtr current_lsn) * refresh for the subscription where we remove the table * state and its origin and by this time the origin might be * already removed. So passing missing_ok = true. + * + * Also Lock SubscriptionRelationId with AccessShareLock to + * prevent any deadlocks with user concurrently performing + * refresh on the subscription. */ + LockSharedObject(SubscriptionRelationId, MyLogicalRepWorker->subid, + 0, AccessShareLock); + ReplicationOriginNameForTablesync(MyLogicalRepWorker->subid, rstate->relid, originname, -- 1.8.3.1