On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
> >> In the bug thread I proposed making atexit_callback check whether getpid()
> >> still matches MyProcPid.
>
> > What are you proposing to do in that case? This is only one of the
> > failure cases of forking carelessly, right?
>
> No, I think it should do nothing. The coding pattern shown in bug #9464
> seems perfectly reasonable and I think we should allow it. No doubt it's
> safer if the child process does an on_exit_reset; but right now, if the
> child fails to do so, atexit_callback is actively breaking things. And
> I don't think we can rely on third-party libraries to call on_exit_reset
> after forking.
I don't think it's a reasonable pattern run background processes that
aren't managed by postgres with all shared memory still
accessible. You'll have to either also detach from shared memory and
related things, or you have to fork() and exec(). At the very least, not
integrating the child with the postmaster's lifetime will prevent
postgres from restarting because there's still a child attached to the
shared memory.
I don't see any way it's be safe for a pg unaware library to start
forking around and doing similar random things inside normal
backends.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services