On Sat, Jan 15, 2011 at 6:27 AM, Florian Pflug <fgp@phlo.org> wrote:
> On Jan14, 2011, at 17:45 , Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug <fgp@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
