Skip to content

Commit f0e3e05

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 9457508 commit f0e3e05

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
@@ -2467,6 +2467,7 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
24672467
if (!proclock)
24682468
{
24692469
LWLockRelease(partitionLock);
2470+
LWLockRelease(proc->backendLock);
24702471
return false;
24712472
}
24722473
GrantLock(proclock->tag.myLock, proclock, lockmode);
@@ -2522,6 +2523,7 @@ FastPathGetRelationLockEntry(LOCALLOCK *locallock)
25222523
if (!proclock)
25232524
{
25242525
LWLockRelease(partitionLock);
2526+
LWLockRelease(MyProc->backendLock);
25252527
ereport(ERROR,
25262528
(errcode(ERRCODE_OUT_OF_MEMORY),
25272529
errmsg("out of shared memory"),
@@ -4011,6 +4013,7 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
40114013
if (!proclock)
40124014
{
40134015
LWLockRelease(partitionLock);
4016+
LWLockRelease(proc->backendLock);
40144017
ereport(ERROR,
40154018
(errcode(ERRCODE_OUT_OF_MEMORY),
40164019
errmsg("out of shared memory"),

0 commit comments

Comments
 (0)