From 360abc0a5be64b01050a9d7144158890236487b5 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 29 Nov 2013 17:35:12 -0500 Subject: [PATCH] Be sure to release proc->backendLock after SetupLockInTable() failure. The various places that transferred fast-path locks to the main lock table neglected to release the PGPROC's backendLock if SetupLockInTable failed due to being out of shared memory. In most cases this is no big deal since ensuing error cleanup would release all held LWLocks anyway. But there are some hot-standby functions that don't consider failure of FastPathTransferRelationLocks to be a hard error, and in those cases this oversight could lead to system lockup. For consistency, make all of these places look the same as FastPathTransferRelationLocks. Noted while looking for the cause of Dan Wood's bugs --- this wasn't it, but it's a bug anyway. --- src/backend/storage/lmgr/lock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c index a6f371566a..3e76102794 100644 --- a/src/backend/storage/lmgr/lock.c +++ b/src/backend/storage/lmgr/lock.c @@ -2537,6 +2537,7 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag if (!proclock) { LWLockRelease(partitionLock); + LWLockRelease(proc->backendLock); return false; } GrantLock(proclock->tag.myLock, proclock, lockmode); @@ -2592,6 +2593,7 @@ FastPathGetRelationLockEntry(LOCALLOCK *locallock) if (!proclock) { LWLockRelease(partitionLock); + LWLockRelease(MyProc->backendLock); ereport(ERROR, (errcode(ERRCODE_OUT_OF_MEMORY), errmsg("out of shared memory"), @@ -4055,6 +4057,7 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait) if (!proclock) { LWLockRelease(partitionLock); + LWLockRelease(proc->backendLock); ereport(ERROR, (errcode(ERRCODE_OUT_OF_MEMORY), errmsg("out of shared memory"), -- 2.40.0