Re: kill -KILL: What happens?

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: kill -KILL: What happens?
Date: 2011-01-15 11:27:07
Message-ID: 2AAD73BE-1AC9-4F25-A912-0AFD3DFF6EE8@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan14, 2011, at 17:45 , Robert Haas wrote:
> On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug <fgp(at)phlo(dot)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.

That parts can also easily be left out by using only one FIFO instead of
two, kept open for writing only in the postmaster.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-01-15 11:29:52 Re: LOCK for non-tables
Previous Message Simon Riggs 2011-01-15 11:24:52 Re: Recovery control functions