Re: BUG #9464: PANIC with 'failed to re-find shared lock object'

Peter LaDow <petela@gocougs.wsu.edu> writes:
> On Thu, Mar 6, 2014 at 7:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> on_exit_reset() in the first-level child would likely be a good idea.

> Thanks for the tip!  I tried it, and things are happy again.

Hah, thanks for confirming the diagnosis.

>> See atexit_callback in src/backend/storage/ipc/ipc.c: your first-level
>> child is killing all the parent backend's shared-memory state when it
>> does exit().  This is a safety feature we added at some point in the

> Ah!  Well, I guess I could use _exit() as well...
> Any preference between the two?

I don't think _exit() is a terribly good idea.  Consider the possibility
that some third-party library loaded into the backend has also established
an atexit callback, and unlike what we did, that code does need to get
control in a subprocess exit.

I'm thinking we failed to consider this situation, and really the right
thing is for atexit_callback() to defend itself against the case.
One possibility is to do this:

atexit_callback(void)
{
    if (getpid() == MyProcPid)
    {
        /* Clean up everything that must be cleaned up */
        /* ... too bad we don't know the real exit code ... */
        proc_exit_prepare(-1);
    }
}

but that's pretty off-the-cuff, so I'm not sure if it still has
failure modes.

Could you try patching atexit_callback as above, and verify that
it does what you want (with or without the on_exit_reset() in your
extension)?

            regards, tom lane