Hi,
On 2014-03-07 10:24:31 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
> >> No, I think it should do nothing. The coding pattern shown in bug #9464
> >> seems perfectly reasonable and I think we should allow it.
>
> > 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().
>
> The code in question is trying to do that. And what do you think will
> happen if the exec() fails?
In code that's written properly, not much. It will use _exit() after the
exec() failure. That's pretty established best practice after forking,
especially after a exec() failure.
> > 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 think you're willfully missing the point. The reason we added
> atexit_callback was to try to defend ourselves against third-party code
> that did things in a non-Postgres-aware way.
Hey, I am not arguing that we should remove protection, I am saying that
we should make it more obvious that dangerous stuff happens. That way
people can fix stuff during development rather than finding out stuff
breaks in some corner cases on busy live systems.
> Arguing that such code
> should do things in a Postgres-aware way is not helpful for the concerns
> here, and it's not relevant to reality either, because people will load
> stuff like libperl into backends. Good luck getting a post-fork
> on_exit_reset() call into libperl.
libperl won't fork on it's own, without the user telling it to do so,
and code that forks can very well be careful to do POSIX::_exit(),
especially in case a exec fails. I don't have much problem telling
people that a fork() without a direct exec() afterwards simply isn't
supported from PLs.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services