Commit 442231d7 authored by Tom Lane's avatar Tom Lane

Fix postmaster to attempt restart after a hot-standby crash.

The postmaster was coded to treat any unexpected exit of the startup
process (i.e., the WAL replay process) as a catastrophic crash, and not try
to restart it. This was OK so long as the startup process could not have
any sibling postmaster children.  However, if a hot-standby backend
crashes, we SIGQUIT the startup process along with everything else, and the
resulting exit is hardly "unexpected".  Treating it as such meant we failed
to restart a standby server after any child crash at all, not only a crash
of the WAL replay process as intended.  Adjust that.  Back-patch to 9.0
where hot standby was introduced.
parent 0ee23b53
...@@ -2311,12 +2311,17 @@ reaper(SIGNAL_ARGS) ...@@ -2311,12 +2311,17 @@ reaper(SIGNAL_ARGS)
} }
/* /*
* Any unexpected exit (including FATAL exit) of the startup * After PM_STARTUP, any unexpected exit (including FATAL exit) of
* process is treated as a crash, except that we don't want to * the startup process is catastrophic, so kill other children,
* reinitialize. * and set RecoveryError so we don't try to reinitialize after
* they're gone. Exception: if FatalError is already set, that
* implies we previously sent the startup process a SIGQUIT, so
* that's probably the reason it died, and we do want to try to
* restart in that case.
*/ */
if (!EXIT_STATUS_0(exitstatus)) if (!EXIT_STATUS_0(exitstatus))
{ {
if (!FatalError)
RecoveryError = true; RecoveryError = true;
HandleChildCrash(pid, exitstatus, HandleChildCrash(pid, exitstatus,
_("startup process")); _("startup process"));
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment