Skip to content

Commit 360abc0

Browse files
committed
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.
1 parent c357be2 commit 360abc0

File tree

1 file changed

+3
-0
lines changed
  • src/backend/storage/lmgr

1 file changed

+3
-0
lines changed

src/backend/storage/lmgr/lock.c

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2537,6 +2537,7 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
25372537
if (!proclock)
25382538
{
25392539
LWLockRelease(partitionLock);
2540+
LWLockRelease(proc->backendLock);
25402541
return false;
25412542
}
25422543
GrantLock(proclock->tag.myLock, proclock, lockmode);
@@ -2592,6 +2593,7 @@ FastPathGetRelationLockEntry(LOCALLOCK *locallock)
25922593
if (!proclock)
25932594
{
25942595
LWLockRelease(partitionLock);
2596+
LWLockRelease(MyProc->backendLock);
25952597
ereport(ERROR,
25962598
(errcode(ERRCODE_OUT_OF_MEMORY),
25972599
errmsg("out of shared memory"),
@@ -4055,6 +4057,7 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
40554057
if (!proclock)
40564058
{
40574059
LWLockRelease(partitionLock);
4060+
LWLockRelease(proc->backendLock);
40584061
ereport(ERROR,
40594062
(errcode(ERRCODE_OUT_OF_MEMORY),
40604063
errmsg("out of shared memory"),

0 commit comments

Comments
 (0)