1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Be sure to release proc->backendLock after SetupLockInTable() failure.

Browse Source 
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.
This commit is contained in:
Tom Lane 2013-11-29 17:35:12 -05:00
parent c357be2cd9
commit 360abc0a5b
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/backend/storage/lmgr/lock.c
View File

@ -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"),