Re: atomic pin/unpin causing errors

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