Tom Lane 8b151558c8 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.		2013-11-29 17:35:09 -05:00
..
buffer	Fix typo in comment.	2013-08-02 09:15:42 -04:00
file	Ensure all files created for a single BufFile have the same resource owner.	2013-11-01 16:09:48 -04:00
freespace	Add buffer_std flag to MarkBufferDirtyHint().	2013-06-17 08:02:12 -07:00
ipc	Fix Hot-Standby initialization of clog and subtrans.	2013-11-22 14:45:41 +02:00
large_object	Fix snapshot leak if lo_open called on non-existent object.	2013-09-30 12:53:14 +03:00
lmgr	Be sure to release proc->backendLock after SetupLockInTable() failure.	2013-11-29 17:35:09 -05:00
page	Cooperate with the Valgrind instrumentation framework.	2013-06-26 20:22:25 -04:00
smgr	pgindent run for release 9.3	2013-05-29 16:58:43 -04:00
Makefile	Remove cvs keywords from all files.	2010-09-20 22:08:53 +02:00