On 7 May 2011 18:07, Tom Lane <t...@sss.pgh.pa.us> wrote: > The aspect of this that *is* relevant is that if you haven't > deliberately defeated the interlock (and thereby put your data at risk), > you won't be able to start a new postmaster until all the old > shmem-attached children are gone. And that's why having a child with a > very long reaction time for parent death represents a denial of service.
Alright. I don't suppose it would be acceptable to have the startup process signal any auxiliary process that it might find with init as a parent through ps, and within the handler for that signal in each auxiliary (I suppose it's a SIGUSR2), take appropriate action, typically just waking up through a SetLatch() call once we independently verify that we are in fact orphaned? If we find orphans, we could perform a "nap and check" loop within the startup process (probably tighter than 1 second per iteration), until the shmem-attached children that are liable to block us from starting a new postmaster exit(). -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
