Re: "multiple backends attempting to wait for pincount 1" - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: "multiple backends attempting to wait for pincount 1"
Date
Msg-id 1533677374.3210544.1423941267990.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Re: "multiple backends attempting to wait for pincount 1"  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> wrote:
> On 2015-02-14 17:25:00 +0000, Kevin Grittner wrote:

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

Oh, I see what you were saying -- I had read that a different way
entirely.  Got 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.

I guess we have some time before the next minor release to find any
problems with this; perhaps the benefit would outweigh the risk.
Anyone else want to weigh in on that?

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

So is the attached more like what you had in mind?  If not, feel
free to post a patch.  :-)

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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "multiple backends attempting to wait for pincount 1"
Next
From: Jim Nasby
Date:
Subject: Re: New CF app deployment