Re: bug in SignalSomeChildren

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug in SignalSomeChildren
Date: 2010-12-17 16:43:45
Message-ID: 1216.1292604225@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2010-12-17 16:44:13 Re: Serializable lock consistency (was Re: CommitFest wrap-up)
Previous Message Magnus Hagander 2010-12-17 16:42:30 Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)