On Sat, Jan 15, 2011 at 6:27 AM, Florian Pflug <f...@phlo.org> wrote: > On Jan14, 2011, at 17:45 , Robert Haas wrote: >> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug <f...@phlo.org> wrote: >>> I gather that the behaviour we want is for normal backends to exit >>> once the postmaster is gone, and for utility processes (bgwriter, ...) >>> to exit once all the backends are gone. >>> >>> The test program I posted in this thread proves that FIFOs and select() >>> can be used to implement this, if we're ready to check for EOF on the >>> socket in CHECK_FOR_INTERRUPTS() every few seconds. Is this a viable >>> route to take? >> >> I don't think there's much point in getting excited about the order in >> which things exit. If we're agreed (and we seem to be, modulo Tom) >> that the backends should exit quickly if the postmaster dies, then >> worrying about whether the utility processes exit slightly before or >> slightly after that doesn't excite me very much. > > Tom seems to think that as our utility processes gain importance, one day > we might require one to outlive all the backends, and that whatever solution > we adopt should allow us to arrange for that. Or at least this how I > understood him.
Well, there's certainly ONE of those already: the logging collector. But it already has its own solution to this problem. -- 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
