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
Message: Re: [PATCH] postmaster: fix stale PM_STARTUP comment

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