On Thu, Aug 20, 2026 at 10:28:53AM +0900, Zexin Li wrote:
> HandleFatalError() loses its Assert(!FatalError) for
> that; the repeated call re-signals children launched since the
> previous call, which this path wants anyway. Nothing is lost by
> exiting: in the wedged state the startup process is never relaunched,
> so the server could never have recovered on its own.
That's also exactly the reason why this impacts only v18 and newer
versions. HandleFatalError() could be called multiple times before
f0b7ab725139, not after it.
Re-adding the shortcut of the startup process that 9b43e6793b0f has
deleted to act as a replacement of HandleChildCrash() when FatalError
is set, leaving the early exit HandleChildCrash() intact works here at
the end. We could edit HandleChildCrash() so as the state machine
advances if we are under pmState == PM_STARTUP, or just give up on
HandleChildCrash() for the startup process entirely, but I cannot get
much excited about that based on what was looking for. We cannot do
an ExitPostmaster() either, or we would be exposed again to the
orphaned process problems that 9b43e6793b0f has addressed (we are
still OK after this patch, retesting a startup failure with a zeroed
WAL segment, test posted on the thread of 9b43e6793b0f to emulate the
orphan case).
--
Michael
