Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 442231d

Browse files
committed
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.
1 parent 0ee23b5 commit 442231d

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

src/backend/postmaster/postmaster.c

+9-4
Original file line numberDiff line numberDiff line change
@@ -2311,13 +2311,18 @@ reaper(SIGNAL_ARGS)
23112311
}
23122312

23132313
/*
2314-
* Any unexpected exit (including FATAL exit) of the startup
2315-
* process is treated as a crash, except that we don't want to
2316-
* reinitialize.
2314+
* After PM_STARTUP, any unexpected exit (including FATAL exit) of
2315+
* the startup process is catastrophic, so kill other children,
2316+
* and set RecoveryError so we don't try to reinitialize after
2317+
* they're gone. Exception: if FatalError is already set, that
2318+
* implies we previously sent the startup process a SIGQUIT, so
2319+
* that's probably the reason it died, and we do want to try to
2320+
* restart in that case.
23172321
*/
23182322
if (!EXIT_STATUS_0(exitstatus))
23192323
{
2320-
RecoveryError = true;
2324+
if (!FatalError)
2325+
RecoveryError = true;
23212326
HandleChildCrash(pid, exitstatus,
23222327
_("startup process"));
23232328
continue;

0 commit comments

Comments
 (0)