Re: bug in SignalSomeChildren - Mailing list pgsql-hackers

From Robert Haas
Subject Re: bug in SignalSomeChildren
Date
Msg-id AANLkTimEae8DKbwHDaH8iV2jzMconPva79jVn2Y5u325@mail.gmail.com
Whole thread Raw
In response to Re: bug in SignalSomeChildren  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bug in SignalSomeChildren  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>>> Attaching gdb to either the startup process or a WAL sender causes
>>>> PostmasterIsAlive to return false, resulting in a near-immediate exit.
>>>>  Seems pretty stupid for attaching gdb to change the return value of
>>>> getppid() but it seems like that must be what's happening.
>
>> Can we add a develop option to force use of the kill(0) method?
>
> How will that avoid needing to have an honest answer from getppid()?
> Without that you can't know what to issue kill() against.

The answer to this question will probably be entirely self-evident if
you stare at PostmasterIsAlive() for, well, it took me about 10
seconds.  So probably less than five for you.

> Seems like the correct path here is to complain to gdb and/or BSD
> upstreams about this misbehavior.

That might be a good thing to do too, but even if they agree to fix it
and do in fact fix it right away, it'll take months or years before
all of the major PostgreSQL contributors can benefit from those fixes,
as opposed to, say, this afternoon.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: bug in SignalSomeChildren
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Extensions, patch v20 (bitrot fixes)