Re: Hot standby fails if any backend crashes

On Fri, Feb 3, 2012 at 1:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> I'm currently working with Duncan Rance's test case for bug #6425, and
>> I am observing a very nasty behavior in HEAD: once one of the
>> hot-standby query backends crashes, the standby postmaster SIGQUIT's
>> all its children and then just quits itself, with no log message and
>> apparently no effort to restart.  Surely this is not intended?
>
> I looked through postmaster.c and found that the cause of this is pretty
> obvious: if the startup process exits with any non-zero status, we
> assume that represents an unrecoverable error condition, and set
> RecoveryError which causes the postmaster to exit silently as soon as
> its last child is gone.  But we do this even if the reason the startup
> process did exit(1) is that we sent it SIGQUIT as a result of a crash of
> some other process.  Of course this logic dates from a time where the
> startup process could not have any siblings, so when it was written,
> such a thing was impossible.
>
> I think saner behavior might only require this change:
>
>            /*
>             * Any unexpected exit (including FATAL exit) of the startup
>             * process is treated as a crash, except that we don't want to
>             * reinitialize.
>             */
>            if (!EXIT_STATUS_0(exitstatus))
>            {
> -               RecoveryError = true;
> +               if (!FatalError)
> +                   RecoveryError = true;
>                HandleChildCrash(pid, exitstatus,
>                                 _("startup process"));
>                continue;
>            }
>
> plus suitable comment adjustments of course.  Haven't tested this yet
> though.

Looks good to me.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center