From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
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-05-07 01:50:48 |
Message-ID: | BANLkTinJo++ZPppJdMD+zO1_pAR_mN0etg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 15, 2011 at 10:44 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> 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.
>
> I've realized that POSIX actually *does* provide a way to receive a signal -
> the SIGIO machinery. I've modified my test case do to that. To simplify things,
> I've removed support for multiple life sign objects.
>
> The code now does the following:
>
> The parents creates a pipe, sets it's reading fd to O_NONBLOCK and O_ASYNC,
> and registers a SIGIO handler. The SIGIO handler checks a global flag, and
> simply sends a SIGTERM to its own pid if the flag is set.
>
> Child processes close the pipe's writing end (called "giving up ownership
> of the life sign" in the code) and set the global flag if they want to receive
> a SIGTERM once the parent is gone. The parent's health state can additionally
> be checked at any time by trying to read() from the pipe. read() returns
> EAGAIN as long as the parent is still alive and EOF otherwise.
>
> I'm not sure how portable this is. It compiles and runs fine on both my linux
> machine (Ubuntu 10.04.01 LTS) and my laptop (OSX 10.6.6).
>
> In the EXEC_BACKEND case the pipe would need to be created with mkfifo() in
> the data directory, but otherwise things should work the same. Haven't tried
> that yet, though.
>
> Code attached. The output should be
>
> Launched backend 8636
> Launched backend 8637
> Launched backend 8638
> Backend 8636 detected live parent
> Backend 8637 detected live parent
> Backend 8638 detected live parent
> Backend 8636 detected live parent
> Backend 8637 detected live parent
> Backend 8638 detected live parent
> Parent exiting
> Backend 8637 exiting after parent died
> Backend 8638 exiting after parent died
> Backend 8636 exiting after parent died
>
> if things work correctly.
Are you planning to develop this into a patch for 9.2?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-07 01:51:39 | Re: (Better) support for cross compiled external modules |
Previous Message | Robert Haas | 2011-05-07 01:35:39 | Re: patch: fix race in SSI's CheckTargetForConflictsIn |