Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8b15155

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 16e1b7a commit 8b15155

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

+3
Original file line numberDiff line numberDiff line change
@@ -2536,6 +2536,7 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
25362536
if (!proclock)
25372537
{
25382538
LWLockRelease(partitionLock);
2539+
LWLockRelease(proc->backendLock);
25392540
return false;
25402541
}
25412542
GrantLock(proclock->tag.myLock, proclock, lockmode);
@@ -2591,6 +2592,7 @@ FastPathGetRelationLockEntry(LOCALLOCK *locallock)
25912592
if (!proclock)
25922593
{
25932594
LWLockRelease(partitionLock);
2595+
LWLockRelease(MyProc->backendLock);
25942596
ereport(ERROR,
25952597
(errcode(ERRCODE_OUT_OF_MEMORY),
25962598
errmsg("out of shared memory"),
@@ -4054,6 +4056,7 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
40544056
if (!proclock)
40554057
{
40564058
LWLockRelease(partitionLock);
4059+
LWLockRelease(proc->backendLock);
40574060
ereport(ERROR,
40584061
(errcode(ERRCODE_OUT_OF_MEMORY),
40594062
errmsg("out of shared memory"),

0 commit comments

Comments
 (0)