Re: atexit_callback can be a net negative
От | Tom Lane |
---|---|
Тема | Re: atexit_callback can be a net negative |
Дата | |
Msg-id | 15521.1394205871@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: atexit_callback can be a net negative (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: atexit_callback can be a net negative
|
Список | pgsql-hackers |
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? > 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
В списке pgsql-hackers по дате отправления: