On 8/29/15 5:52 PM, Jeff Janes wrote:
! Obtaining the necessary lock is done by the bufmgr routines ! LockBufferForCleanup() or ConditionalLockBufferForCleanup(). ! They first get an exclusive lock and then check to see if the shared pin ! count is currently 1. If not, ConditionalLockBufferForCleanup() releases ! the exclusive lock and then returns false, while LockBufferForCleanup() ! releases the exclusive lock (but not the caller's pin) and waits until ! signaled by another backend, whereupon it tries again. The signal will ! occur when UnpinBuffer decrements the shared pin count to 1. AsI don't think that's true. If 2 other backends have a pin then AFAIK you'd wake up twice. There's also this comment in LockBufferForCleanup: /* * Remove flag marking us as waiter. Normally this will not be set * anymore, but ProcWaitForSignal() can return for other signals as * well. We take care to only reset the flag if we're the waiter, as * theoretically another backend could have started waiting. That's * impossible with the current usages due to table level locking, but * better be safe. */ If 2 other backends have a pin, only the last one to drop it should do the waking. I don't see a way they could both try to do the waking, the interlock on the buffer header seems to prevent that. But if it did, that would just be another way you could have a spurious wake-up, which can already happen for other reasons. I don't think the spurious wake up needs to be documented in the higher level README file.
My concern is someone will read too much into "signal will occur ... count to 1" and think there's no other ways to be woken up. I realize I'm being pedantic here, but given the nasty race condition bugs we've had lately maybe it's warranted.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
