Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use proc_exit() for walreceiver exit in WalRcvWaitForStartPosition()

  1. Use proc_exit() in WalRcvWaitForStartPosition

    Chao Li <li.evan.chao@gmail.com> — 2026-04-08T09:08:36Z

    Hi,

While working on another patch, I happened to notice that WalRcvWaitForStartPosition() calls raw exit(1). I think this should use proc_exit(1) instead, so that the normal cleanup machinery is not bypassed.

This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWaitForStartPosition().

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  2. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Andreas Karlsson <andreas@proxel.se> — 2026-04-08T20:59:52Z

    On 4/8/26 11:08 AM, Chao Li wrote:
> While working on another patch, I happened to notice that WalRcvWaitForStartPosition() calls raw exit(1). I think this should use proc_exit(1) instead, so that the normal cleanup machinery is not bypassed.
> 
> This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWaitForStartPosition().

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 those 
two cases are different.

Andreas

  3. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Xuneng Zhou <xunengzhou@gmail.com> — 2026-04-09T01:09:08Z

    On Thu, Apr 9, 2026 at 5:00 AM Andreas Karlsson <andreas@proxel.se> wrote:
>
> On 4/8/26 11:08 AM, Chao Li wrote:
> > While working on another patch, I happened to notice that WalRcvWaitForStartPosition() calls raw exit(1). I think this should use proc_exit(1) instead, so that the normal cleanup machinery is not bypassed.
> >
> > This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWaitForStartPosition().
>
> 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 those
> two cases are different.

+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.

-- 
Best,
Xuneng

  4. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Fujii Masao <masao.fujii@gmail.com> — 2026-04-10T06:16:37Z

    On Thu, Apr 9, 2026 at 10:09 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
>
> On Thu, Apr 9, 2026 at 5:00 AM Andreas Karlsson <andreas@proxel.se> wrote:
> >
> > On 4/8/26 11:08 AM, Chao Li wrote:
> > > While working on another patch, I happened to notice that WalRcvWaitForStartPosition() calls raw exit(1). I think this should use proc_exit(1) instead, so that the normal cleanup machinery is not bypassed.
> > >
> > > This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWaitForStartPosition().
> >
> > 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 those
> > 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), resulting
in exit code 1. In contrast, if it exits early in WalRcvWaitForStartPosition()
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 fine
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,

-- 
Fujii Masao

  5. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Chao Li <li.evan.chao@gmail.com> — 2026-04-10T07:07:03Z

    
> On Apr 10, 2026, at 14:16, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Thu, Apr 9, 2026 at 10:09 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
>> 
>> On Thu, Apr 9, 2026 at 5:00 AM Andreas Karlsson <andreas@proxel.se> wrote:
>>> 
>>> On 4/8/26 11:08 AM, Chao Li wrote:
>>>> While working on another patch, I happened to notice that WalRcvWaitForStartPosition() calls raw exit(1). I think this should use proc_exit(1) instead, so that the normal cleanup machinery is not bypassed.
>>>> 
>>>> This tiny patch just replaces exit(1) with proc_exit(1) in WalRcvWaitForStartPosition().
>>> 
>>> 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 those
>>> 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), resulting
> in exit code 1. In contrast, if it exits early in WalRcvWaitForStartPosition()
> 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 fine
> 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,
> 
> -- 
> Fujii Masao

PFA v2 - updated header comment of walreceive.c. I tried to avoid mentioning the exact exit value in the comment, so I just changed “exit(0)” to “terminate”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  6. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Fujii Masao <masao.fujii@gmail.com> — 2026-04-10T14:17:29Z

    On Fri, Apr 10, 2026 at 4:07 PM Chao Li <li.evan.chao@gmail.com> wrote:
> PFA v2 - updated header comment of walreceive.c. I tried to avoid mentioning the exact exit value in the comment, so I just changed “exit(0)” to “terminate”.

Thanks for updating the patch!

"termination instructs XXX to terminate" sounds a bit redundant. How
about saying
"to ereport(FATAL)" instead of “to terminate”?

Regards,


-- 
Fujii Masao

  7. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Chao Li <li.evan.chao@gmail.com> — 2026-04-12T23:33:02Z

    
> On Apr 10, 2026, at 22:17, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Fri, Apr 10, 2026 at 4:07 PM Chao Li <li.evan.chao@gmail.com> wrote:
>> PFA v2 - updated header comment of walreceive.c. I tried to avoid mentioning the exact exit value in the comment, so I just changed “exit(0)” to “terminate”.
> 
> Thanks for updating the patch!
> 
> "termination instructs XXX to terminate" sounds a bit redundant. How
> about saying
> "to ereport(FATAL)" instead of “to terminate”?
> 
> Regards,
> 
> 
> -- 
> Fujii Masao


Okay, yes, that was a bit redundant. I changed it to “to ereport(FATAL)” in v3.

After that change, the line went over 80 columns, so I also adjusted a few nearby lines to keep everything within the 80-column limit. There is no content change.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  8. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Fujii Masao <masao.fujii@gmail.com> — 2026-04-16T03:34:40Z

    On Mon, Apr 13, 2026 at 8:33 AM Chao Li <li.evan.chao@gmail.com> wrote:
> Okay, yes, that was a bit redundant. I changed it to “to ereport(FATAL)” in v3.
>
> After that change, the line went over 80 columns, so I also adjusted a few nearby lines to keep everything within the 80-column limit. There is no content change.

Thanks for updating the patch! I've pushed it.

Regards,

-- 
Fujii Masao

  9. Re: Use proc_exit() in WalRcvWaitForStartPosition

    Chao Li <li.evan.chao@gmail.com> — 2026-04-16T04:02:48Z

    
> On Apr 16, 2026, at 11:34, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Mon, Apr 13, 2026 at 8:33 AM Chao Li <li.evan.chao@gmail.com> wrote:
>> Okay, yes, that was a bit redundant. I changed it to “to ereport(FATAL)” in v3.
>> 
>> After that change, the line went over 80 columns, so I also adjusted a few nearby lines to keep everything within the 80-column limit. There is no content change.
> 
> Thanks for updating the patch! I've pushed it.
> 
> Regards,
> 
> -- 
> Fujii Masao

Hi Fujii san, thank you very much for pushing.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/