MIME-Version: 1.0
References: 
 <CAJTYsWVoD3V9yhhqSae1_wqcnTdpFY-hDT7dPm5005ZFsL_bpA@mail.gmail.com>
 <0f462532-9790-4334-b503-4ee522225820@iki.fi>
In-Reply-To: <0f462532-9790-4334-b503-4ee522225820@iki.fi>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Wed, 15 Apr 2026 23:31:10 +0530
Message-ID: 
 <CAJTYsWVw3h1hTDyUdaDb8MmmXF0qQKzV3YkQUwC1DhvcApFvTw@mail.gmail.com>
Subject: Re: [PATCH] postmaster: fix stale PM_STARTUP comment
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers@postgresql.org, "noah@leadboat.com" <noah@leadboat.com>
Content-Type: multipart/alternative; boundary="000000000000f96387064f8380a1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWVw3h1hTDyUdaDb8MmmXF0qQKzV3YkQUwC1DhvcApFvTw%40mail.gmail.com>
Precedence: bulk

--000000000000f96387064f8380a1
Content-Type: text/plain; charset="UTF-8"

Hi

On Wed, 15 Apr 2026 at 22:21, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

> On 15/04/2026 16:57, Ayush Tiwari wrote:
> > Hi,
> >
> > The comment above the PM_STARTUP startup-process-failure case still says
> > that there are no other processes running yet, so the postmaster can just
> > exit.
> >
> > That no longer matches the current startup flow: PM_STARTUP may already
> > have auxiliary processes running by that point. The attached patch
> updates
> > that comment to describe the current behavior.
>
> Hmm, shouldn't the postmaster kill and wait for the auxiliary processes
> to exit first in that case? ISTM we need code changes here, not just
> comments.
>
> - Heikki
>
>
Yes, I agree, code change is required here.

The proper thing is to
route this through the existing crash-handling path so the postmaster
SIGQUITs the aux children and waits for them to exit before terminating.

I think the minimal change is:

  1. Replace the ExitPostmaster(1) shortcut in the PM_STARTUP
     startup-failure case with HandleChildCrash(), which calls
     TerminateChildren(SIGQUIT) and transitions through the state
     machine.  Set StartupStatus = STARTUP_CRASHED so the state
     machine does not try to reinitialize.

  2. Let HandleFatalError() handle PM_STARTUP by transitioning to
     PM_WAIT_BACKENDS, instead of the current Assert(false).

The state machine already handles STARTUP_CRASHED at PM_NO_CHILDREN
("shutting down due to startup process failure"), so the exit path is
already correct once all children have drained.

This issue was discussed in an older thread by Noah too, so, adding him in
cc.

I can send in a proper patch if you think this is the right way to go.

Regards,
Ayush

--000000000000f96387064f8380a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi</div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 15 Apr 20=
26 at 22:21, Heikki Linnakangas &lt;<a href=3D"mailto:hlinnaka@iki.fi">hlin=
naka@iki.fi</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On 15/04/2026 16:57, Ayush Tiwari wrote:<br>
&gt; Hi,<br>
&gt; <br>
&gt; The comment above the PM_STARTUP startup-process-failure case still sa=
ys<br>
&gt; that there are no other processes running yet, so the postmaster can j=
ust<br>
&gt; exit.<br>
&gt; <br>
&gt; That no longer matches the current startup flow: PM_STARTUP may alread=
y<br>
&gt; have auxiliary processes running by that point. The attached patch upd=
ates<br>
&gt; that comment to describe the current behavior.<br>
<br>
Hmm, shouldn&#39;t the postmaster kill and wait for the auxiliary processes=
 <br>
to exit first in that case? ISTM we need code changes here, not just <br>
comments.<br>
<br>
- Heikki<br>
<br></blockquote><div><br></div><div>Yes, I agree, code change is required =
here.<br><br>The proper thing is to<br>route this through the existing cras=
h-handling path so the postmaster<br>SIGQUITs the aux children and waits fo=
r them to exit before terminating.<br><br>I think the minimal change is:<br=
><br>=C2=A0 1. Replace the ExitPostmaster(1) shortcut in the PM_STARTUP<br>=
=C2=A0 =C2=A0 =C2=A0startup-failure case with HandleChildCrash(), which cal=
ls<br>=C2=A0 =C2=A0 =C2=A0TerminateChildren(SIGQUIT) and transitions throug=
h the state<br>=C2=A0 =C2=A0 =C2=A0machine.=C2=A0 Set StartupStatus =3D STA=
RTUP_CRASHED so the state<br>=C2=A0 =C2=A0 =C2=A0machine does not try to re=
initialize.<br><br>=C2=A0 2. Let HandleFatalError() handle PM_STARTUP by tr=
ansitioning to<br>=C2=A0 =C2=A0 =C2=A0PM_WAIT_BACKENDS, instead of the curr=
ent Assert(false).<br><br>The state machine already handles STARTUP_CRASHED=
 at PM_NO_CHILDREN<br>(&quot;shutting down due to startup process failure&q=
uot;), so the exit path is<br>already correct once all children have draine=
d.<br><br>This issue was discussed in an older thread by Noah too, so, addi=
ng him in cc.<br><br>I can send in a proper patch if you think this is the =
right way to go.<br><br>Regards,<br>Ayush</div></div></div>

--000000000000f96387064f8380a1--