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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to