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. As
>
>
> I 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
