Fix two more bugs in fast-path relation locking. fastlock91
authorRobert Haas <[email protected]>
Wed, 30 May 2012 20:17:46 +0000 (16:17 -0400)
committerRobert Haas <[email protected]>
Fri, 1 Jun 2012 12:32:56 +0000 (08:32 -0400)
commita98e9a2da15e44b132add78a49f12f3e0a240b8f
tree091f37b9d59f4dcf37f5afb6e3bdfeea09d3392b
parent59d783b81a5baadc5e80f857b3e3c6cab1790cd2
Fix two more bugs in fast-path relation locking.

First, the previous code failed to account for the fact that, during Hot
Standby operation, the startup process takes AccessExclusiveLocks on
relations without setting MyDatabaseId.  This resulted in fast path
strong lock counts failing to be incremented with the startup process
took locks, which in turn allowed conflicting lock requests to succeed
when they should not have.  Report by Erik Rijkers, diagnosis by Heikki
Linnakangas.

Second, LockReleaseAll() failed to honor the allLocks and lockmethodid
restrictions with respect to fast-path locks.  It's not clear to me
whether this produces any user-visible breakage at the moment, but it's
certainly wrong.  Rearrange order of operations in LockReleaseAll to fix.
Noted by Tom Lane.
src/backend/storage/lmgr/lock.c