Hi,
Thanks a lot for the review!.
On Fri, Apr 17, 2026 at 07:17:18PM +0530, Ayush Tiwari wrote:
> I've attached a patch, please review and let me know your thoughts.
/*
- * 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))
The assumption that only the startup process is running while we are
in a PM_STARTUP state is wrong since 7ff23c6d277d, and this exit code
path has been missed the fact that now the checkpointer and the
bgwriter are started during recovery. So this means a backpatch.
Agreed, this is latent since 7ff23c6d277d (v15). I can prepare a back-branch
versions patch for v15..master once the master patch shape is settled
Removing the assertion is the right move, yes, there are other
children, so again that's an issue with 7ff23c6d277d. I am planning
to double-check the shutdown sequence while switching to
PM_WAIT_BACKENDS under a PM_STARTUP, just note that bgworkers that use
BgWorkerStart_PostmasterStart cannot request a database connection,
meaning that PM_WAIT_BACKENDS should be pointeless, but perhaps it
makes the whole shutdown flow easier to reason about, as you are
suggesting, as making this path more complicated would lead to the
addition of more postmaster states. Making this code simpler, not
more complicated, is always useful.
--
Michael
Right, I believe at PM_STARTUP the only children we can possibly have are
the auxiliary processes (checkpointer, bgwriter, walwriter (if applicable),
IO workers) and BgWorkerStart_PostmasterStart bgworkers,
none of which should hold backend slots. So, PM_WAIT_BACKENDS is functionally
a no-op in this case and we transition straight through to
PM_WAIT_DEAD_END.
I considered short-circuiting directly to
PM_WAIT_DEAD_END from PM_STARTUP, but routing through the same
state path the rest of the crash-handling code uses keeps the state machine
uniform and avoids a special case in HandleFatalError() / PostmasterStateMachine().
Making the code simpler, as you mentioned.
Regards,
Ayush
