Re: bug in SignalSomeChildren

On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
>>> I think what we ought to be looking to do is get rid of the distinction,
>>> so that the postmaster treats walsenders the same as other children.
>
>> I think the problem with this is that walsenders are treated in a very
>> special way during shutdown -- they need to stay up until after bgwriter
>> is gone.
>
> Why do they need to survive the bgwriter?  And more to the point, why
> does that logic need to be implemented on the postmaster side?  Since
> only the child process really knows reliably whether it's a walsender,
> it'd be far safer if the behavioral difference could be handled on the
> child side.  I haven't looked at the details, but I'm wondering if we
> couldn't make this go by having walsender children react differently
> to the same signals the postmaster sends other children.

I'm not too sure we're shutting down the WAL senders right now. I
think they may just be exiting on their own when the postmaster goes
away.

/*
* Emergency bailout if postmaster has died. This is
to avoid the
* necessity for manual cleanup of all postmaster children.
*/
if (!PostmasterIsAlive(true))
exit(1);

I'm having a bit of trouble confirming this on MacOS X, though.
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.

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