On 2015-02-13 23:05:16 +0000, Kevin Grittner wrote: > Andres Freund <and...@2ndquadrant.com> wrote: > > > How did you get to that recipe? > > I have been working on some patches to allow vacuum to function in > the face of long-held snapshots. (I'm struggling to get them into > presentable shape for the upcoming CF.) I was devising the most > diabolical cases I could to try to break my patched code and > started seeing this error. I was panicked that I had introduced > the bug, but on comparing to the master branch I found I was able > to cause it there, too. So I saw this a couple days before the > report on list, and had some cases that *sometimes* caused the > error. I tweaked until it seemed to be pretty reliable, and then > used that for the bisect. > > I still consider you to be the uncontested champion of diabolical > test cases, but I'm happy to have hit upon one that was useful > here. ;-)
Hah. Not sure if that's something to be proud of :P I don't think it's actually 675333 at fault here. I think it's a long standing bug in LockBufferForCleanup() that can just much easier be hit with the new interrupt code. 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. If you just gdb into the VACUUM process with 6647248e370884 checked out, and do a PGSemaphoreUnlock(&MyProc->sem) you'll hit it as well. I think we should simply move the buf->flags &= ~BM_PIN_COUNT_WAITER (Inside LockBuffer) to LockBufferForCleanup, besides the PinCountWaitBuf = NULL. Afaics, that should do the trick. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
