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

Commit ef19c9d

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 c74ad4e commit ef19c9d

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

src/backend/postmaster/postmaster.c

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2391,13 +2391,18 @@ reaper(SIGNAL_ARGS)
23912391
}
23922392

23932393
/*
2394-
* Any unexpected exit (including FATAL exit) of the startup
2395-
* process is treated as a crash, except that we don't want to
2396-
* reinitialize.
2394+
* After PM_STARTUP, any unexpected exit (including FATAL exit) of
2395+
* the startup process is catastrophic, so kill other children,
2396+
* and set RecoveryError so we don't try to reinitialize after
2397+
* they're gone. Exception: if FatalError is already set, that
2398+
* implies we previously sent the startup process a SIGQUIT, so
2399+
* that's probably the reason it died, and we do want to try to
2400+
* restart in that case.
23972401
*/
23982402
if (!EXIT_STATUS_0(exitstatus))
23992403
{
2400-
RecoveryError = true;
2404+
if (!FatalError)
2405+
RecoveryError = true;
24012406
HandleChildCrash(pid, exitstatus,
24022407
_("startup process"));
24032408
continue;

0 commit comments

Comments
 (0)