On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane <t...@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). Without calling those function, there's no way for code running in the postmaster to call on_dsm_detach(), because it's got nothing to pass for the first argument. In case you're wondering, the major reason I disallowed this is that the control segment tracks the number of backends attached to each segment, and there's no provision for adjusting that value each time the postmaster forks. We could add such provision, but it seems like there would be race conditions, and the postmaster might have to participate in locking, so it might be pretty ugly, and a performance suck for anyone who doesn't need this functionality. And it doesn't seem very useful anyway. The postmaster really shouldn't be touching any shared memory segment more than the absolutely minimal amount, so the main possible benefit I can see is that you could have the mapping already in place for each new backend rather than having to set it up in every backend. But I'm prepared to hope that isn't actually important enough to be worth worrying about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
