On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.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
thereturn value of
getppid() but it seems like that must be what's happening.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company