]> granicus.if.org Git - postgresql/commit
Be sure to release proc->backendLock after SetupLockInTable() failure.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Nov 2013 22:35:12 +0000 (17:35 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Nov 2013 22:35:12 +0000 (17:35 -0500)
commit360abc0a5be64b01050a9d7144158890236487b5
tree03d6bd4a48cfc39aa4b433f1036b942a58a6babb
parentc357be2cd9434c70904d871d9b96828b31a50cc5
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