Andres Freund <and...@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?
> 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. 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
