MIME-Version: 1.0
References: <74381238-4E8A-4621-B794-57025DCCE0BA@gmail.com>
 <6a42c40e-eb81-4212-9bca-8c0eb02d47d1@proxel.se>
 <CABPTF7V=y2rHC=gLTeC-42aRc+jcXueomUBjbNiy3pOfhJs3_A@mail.gmail.com>
In-Reply-To: 
 <CABPTF7V=y2rHC=gLTeC-42aRc+jcXueomUBjbNiy3pOfhJs3_A@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Fri, 10 Apr 2026 15:16:37 +0900
Message-ID: 
 <CAHGQGwHHrDv8Z=D-UP+-RUR2yntv3Ab=yw4_uPWEMY0vLX_O6g@mail.gmail.com>
Subject: Re: Use proc_exit() in WalRcvWaitForStartPosition
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Andreas Karlsson <andreas@proxel.se>, Chao Li <li.evan.chao@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwHHrDv8Z%3DD-UP%2B-RUR2yntv3Ab%3Dyw4_uPWEMY0vLX_O6g%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 9, 2026 at 10:09=E2=80=AFAM Xuneng Zhou <xunengzhou@gmail.com> =
wrote:
>
> On Thu, Apr 9, 2026 at 5:00=E2=80=AFAM Andreas Karlsson <andreas@proxel.s=
e> wrote:
> >
> > On 4/8/26 11:08 AM, Chao Li wrote:
> > > While working on another patch, I happened to notice that WalRcvWaitF=
orStartPosition() calls raw exit(1). I think this should use proc_exit(1) i=
nstead, so that the normal cleanup machinery is not bypassed.
> > >
> > > This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWait=
ForStartPosition().
> >
> > This looks likely to be correct since when we exit in WalReceiverMain()
> > (on WALRCV_STOPPING and WALRCV_STOPPED) we call proc_exit(1). I feel we
> > should exit the same way in WalRcvWaitForStartPosition() as we do in
> > WalReceiverMain() and if not I would like a comment explaining why thos=
e
> > two cases are different.
>
> +1

+1


> WalRcvWaitForStartPosition, WALRCV_STOPPING before entering wait loop
> uses proc_exit(0) for WALRCV_STOPPING, while this path should probably
> use proc_exit(0) as well (not proc_exit(1)), since the stop was a
> requested shutdown, not an error. Using exit code 1 for a clean
> stop-on-request seems inconsistent.

The requested shutdown is handled in ShutdownWalRcv(), which sets the state=
 to
WALRCV_STOPPING and sends SIGTERM to the walreceiver.

Although this might be considered a normal shutdown (suggesting exit code 0=
),
when the walreceiver receives SIGTERM it exits via ereport(FATAL), resultin=
g
in exit code 1. In contrast, if it exits early in WalRcvWaitForStartPositio=
n()
due to the WALRCV_STOPPING state, it uses exit code 0, as you noted. So
there seems to be some inconsistency in exit codes.

That said, the exit code (0 vs 1) does not affect behavior, since
the postmaster treats both as non-crash exits.

For consistency, I would prefer using exit code 1 in proc_exit() in
WalRcvWaitForStartPosition(), to match the ereport(FATAL) path. But I'm fin=
e
with other approaches as well.

Also, the comment at the top of walreceiver.c may need updating:

 * Normal termination is by SIGTERM, which instructs the walreceiver to
 * exit(0). Emergency termination is by SIGQUIT; like any postmaster child
 * process, the walreceiver will simply abort and exit on SIGQUIT. A close
 * of the connection and a FATAL error are treated not as a crash but as
 * normal operation.

Regards,

--=20
Fujii Masao