On 2014-03-07 14:14:17 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-03-07 13:54:42 -0500, Tom Lane wrote: > >> The big picture here is that in the scenario being debated in the other > >> thread, exit() in a child process forked from a backend will execute that > >> backend's on_detach actions *even if the code had done on_exit_reset after > >> the fork*. > > > Hm, aren't those actions called via shmem_exit() calling > > dsm_backend_shutdown() et al? I think that should be cleared by > > on_shmem_exit()? > > But dsm_backend_shutdown gets called whether or not any shmem_exit > actions are registered.
Yikes. I thought on_exit_reset() disarmed the atexit callback, but indeed, it does not... > > I think you're misunderstanding me. I am saying we *should* defend > > against it. Our opinions just seem to differ on what to do when the > > scenario is detected. I am saying we should scream bloody murder (which > > admittedly is a hard in a child), you want to essentially declare it > > supported. > > And if we scream bloody murder, what will happen? Absolutely nothing > except we'll annoy our users. They won't have control over the > third-party libraries that are doing what you want to complain about. If the third party library is suitably careful it will only use fork() and then exec() or _exit(), otherwise there are other things that'll be broken (e.g. stdio). In that case everything was and is fine. If not, the library's user can then fix or file a bug against the library. Both perl and glibc seem to do just that in system() btw... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers