Re: "multiple backends attempting to wait for pincount 1"

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: "multiple backends attempting to wait for pincount 1"
Date: 2015-02-14 17:56:03
Message-ID: 20150214175603.GB15326@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-02-14 17:25:00 +0000, Kevin Grittner wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > Imagine what happens in LockBufferForCleanup() when
> > ProcWaitForSignal() returns spuriously - something it's
> > documented to possibly do (and which got more likely with the new
> > patches). In the normal case UnpinBuffer() will have unset
> > BM_PIN_COUNT_WAITER - but in a spurious return it'll still be set
> > and LockBufferForCleanup() will see it still set.
>
> That analysis makes sense to me.
>
> > I think we should simply move the
> > buf->flags &= ~BM_PIN_COUNT_WAITER (Inside LockBuffer)
>
> I think you meant inside UnpinBuffer?

No, LockBufferHdr. What I meant was that the pincount can only be
manipulated while the buffer header spinlock is held.

> > to LockBufferForCleanup, besides the PinCountWaitBuf = NULL.
> > Afaics, that should do the trick.
>
> I tried that on the master branch (33e879c) (attached) and it
> passes `make check-world` with no problems. I'm reviewing the
> places that BM_PIN_COUNT_WAITER appears, to see if I can spot any
> flaw in this. Does anyone else see a problem with it? Even though
> it appears to be a long-standing bug, there don't appear to have
> been any field reports, so it doesn't seem like something to
> back-patch.

I was wondering about that as well. But I don't think I agree. The most
likely scenario for this to fail is in full table vacuums that have to
freeze rows - those are primarily triggered by autovacuum. I don't think
it's likely that such a error message would be discovered in the logs
unless it happens very regularly.

> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

> diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
> index e1e6240..40b2194 100644
> --- a/src/backend/storage/buffer/bufmgr.c
> +++ b/src/backend/storage/buffer/bufmgr.c
> @@ -1548,7 +1548,6 @@ UnpinBuffer(volatile BufferDesc *buf, bool fixOwner)
> /* we just released the last pin other than the waiter's */
> int wait_backend_pid = buf->wait_backend_pid;
>
> - buf->flags &= ~BM_PIN_COUNT_WAITER;
> UnlockBufHdr(buf);
> ProcSendSignal(wait_backend_pid);
> }
> @@ -3273,6 +3272,7 @@ LockBufferForCleanup(Buffer buffer)
> else
> ProcWaitForSignal();
>
> + bufHdr->flags &= ~BM_PIN_COUNT_WAITER;
> PinCountWaitBuf = NULL;
> /* Loop back and try again */
> }

You can't manipulate flags without holding the spinlock. Otherwise you
(or the other writer) can easily cancel the other sides effects.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henry B (Hank) Hotz, CISSP 2015-02-14 18:12:03 Re: reducing our reliance on MD5
Previous Message Tom Lane 2015-02-14 17:53:58 Re: Manipulating complex types as non-contiguous structures in-memory