On 2016-05-06 11:15:03 -0700, Jeff Janes wrote: > > Running the test with cassert enabled I actually get assertion failures, > > due to the FATAL you added. > > > > #1 0x0000000000958dde in ExceptionalCondition (conditionName=0xb36c2a > > "!(RefCountErrors == 0)", errorType=0xb361af "FailedAssertion", > > fileName=0xb36170 > > "/home/admin/src/postgresql/src/backend/storage/buffer/bufmgr.c", > > lineNumber=2506) at > > /home/admin/src/postgresql/src/backend/utils/error/assert.c:54 > > #2 0x00000000007c9fc9 in CheckForBufferLeaks () at > > /home/admin/src/postgresql/src/backend/storage/buffer/bufmgr.c:2506 > ... > > > > You didn't see those? > > Yes, I have been seeing those on assert-enabled builds going back as > far as I can remember (long before this particular problem started > showing up). > \I just assumed it was a natural consequence of throwing > an ERROR from inside a critical section.
There's no critical section here... The reason we're restarting is because the FATAL makes the checkpointer exit, which postmaster treats as a cause to trigger a PANIC: /* * Any unexpected exit of the checkpointer (including FATAL * exit) is treated as a crash. */ HandleChildCrash(pid, exitstatus, _("checkpointer process")); > I never really understood > it, why would a panicking process bother to check for buffer leaks in > the first place? It is leaking everything, which is why the entire > system has to be brought down immediately. Panicing ones don't... > I have been trying (and failing) to reproduce the problem in more > recent releases, with and without cassert. Here is pg_config output > of one of my current attempts: If you say "recent releases" you mean that you've not been able to reproduce it in 9.5, 9.4, ..., not that the issue has vanished in master, right? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers