0001-postmaster-drain-aux-processes-on-startup-process-fa.patch
application/octet-stream
Filename: 0001-postmaster-drain-aux-processes-on-startup-process-fa.patch
Type: application/octet-stream
Part: 0
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: format-patch
Series: patch 0001
Subject: postmaster: drain aux processes on startup-process failure during PM_STARTUP
| File | + | − |
|---|---|---|
| src/backend/postmaster/postmaster.c | 5 | 24 |
From 6267a416cc773cc88fe17322908961128764c254 Mon Sep 17 00:00:00 2001
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Fri, 17 Apr 2026 18:49:34 +0530
Subject: [PATCH] postmaster: drain aux processes on startup-process failure
during PM_STARTUP
When the startup process exits with a non-zero status during PM_STARTUP,
the postmaster called ExitPostmaster(1) immediately. But by the time
PM_STARTUP is active, checkpointer, bgwriter, io workers, and
BgWorkerStart_PostmasterStart background workers may already be running.
Exiting immediately orphaned them.
Route this path through the existing crash-handling machinery: fall
through to the following stanza which sets StartupStatus = STARTUP_CRASHED
and calls HandleChildCrash(), causing HandleFatalError() to SIGQUIT the
aux children and transition to PM_WAIT_BACKENDS. The state machine then
drains through PM_WAIT_DEAD_END to PM_NO_CHILDREN, where the existing
STARTUP_CRASHED check logs 'shutting down due to startup process failure'
and calls ExitPostmaster(1).
Also replace the Assert(false) for PM_STARTUP in HandleFatalError() with
a transition to PM_WAIT_BACKENDS. The assert was a latent bug: any aux
process crash during PM_STARTUP (not just startup-process failure) would
reach it via HandleChildCrash -> HandleFatalError.
---
src/backend/postmaster/postmaster.c | 29 +++++------------------------
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b6fd332f196..01df0f634e3 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -2305,26 +2305,10 @@ process_pm_child_exit(void)
}
/*
- * Unexpected exit of startup process (including FATAL exit)
- * during PM_STARTUP is treated as catastrophic. There are no
- * other processes running yet, so we can just exit.
- */
- if (pmState == PM_STARTUP &&
- StartupStatus != STARTUP_SIGNALED &&
- !EXIT_STATUS_0(exitstatus))
- {
- LogChildExit(LOG, _("startup process"),
- pid, exitstatus);
- ereport(LOG,
- (errmsg("aborting startup due to startup process failure")));
- ExitPostmaster(1);
- }
-
- /*
- * After PM_STARTUP, any unexpected exit (including FATAL exit) of
- * the startup process is catastrophic, so kill other children,
- * and set StartupStatus so we don't try to reinitialize after
- * they're gone. Exception: if StartupStatus is STARTUP_SIGNALED,
+ * Any unexpected exit (including FATAL exit) of the startup
+ * process is catastrophic, so kill other children, and set
+ * StartupStatus so we don't try to reinitialize after they're
+ * gone. Exception: if StartupStatus is STARTUP_SIGNALED,
* then 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.
@@ -2780,12 +2764,9 @@ HandleFatalError(QuitSignalReason reason, bool consider_sigabrt)
/* shouldn't have any children */
Assert(false);
break;
- case PM_STARTUP:
- /* should have been handled in process_pm_child_exit */
- Assert(false);
- break;
/* wait for children to die */
+ case PM_STARTUP:
case PM_RECOVERY:
case PM_HOT_STANDBY:
case PM_RUN:
--
2.34.1