Re: "multiple backends attempting to wait for pincount 1"
От | Kevin Grittner |
---|---|
Тема | Re: "multiple backends attempting to wait for pincount 1" |
Дата | |
Msg-id | 1533677374.3210544.1423941267990.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: "multiple backends attempting to wait for pincount 1" (Andres Freund <andres@2ndquadrant.com>) |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: