Hi, On 2014-03-07 13:54:42 -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > I don't think this can actually happen. There are quite a number of > > things that would go belly-up if you tried to use dynamic shared > > memory from the postmaster, which is why dsm_create() and dsm_attach() > > both Assert(IsUnderPostmaster). > > Nonetheless it seems like a good idea to make on_exit_reset drop any > such queued actions. > > 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()? > So whether or not you buy Andres' argument that it's not > necessary for atexit_callback to defend against this scenario, there's > actually no other defense possible given the way things work in HEAD. 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. 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
