On Fri, Mar 7, 2014 at 1:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I just noticed that the DSM patch has introduced a whole new class of
>>> failures related to the bug #9464 issue: to wit, any on_detach
>>> actions registered in a parent process will also be performed when a
>>> child process exits, because nothing has been added to on_exit_reset
>>> to prevent that. It seems likely that this is undesirable.
>
>> 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*.
Hmm. So the problematic sequence of events is where a postmaster
child forks, and then exits without exec-ing, perhaps because e.g.
exec fails?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company