Re: restore_command return code behaviour

On Mon, Jul 28, 2025 at 2:22 PM Jacob Champion <
jacob(dot)champion(at)enterprisedb(dot)com> wrote:

> On Mon, Jul 28, 2025 at 1:58 PM Jean-Christophe Arnu <jcarnu(at)gmail(dot)com>
> wrote:
> > Or
> >
> > The recovery will be aborted and the server will stop if any of the
> following events occur:
> > - the command was terminated by a signal other than SIGTERM (which is
> used as part of a database server shutdown);
> > - the command returns an exit code greater than 125
> > - the shell returns an error (such as 'command not found')
> >
> > The former has a 'heavier' style; the latter has the benefit of clearly
> showing each condition for shutting down the server (but it breaks the GUC
> style, where bullet points are only used for defining possible values).
>
> I like the latter. Riffing on that, we could collapse the bullet
> points and reuse a bit of the current wording:
>
> Recovery will abort and the server will not start up if any of the
> following events occur: the command is terminated by a signal other
> than SIGTERM (which is used as part of a database server shutdown);
> the command returns an exit status greater than 125; or the shell
> returns an error, such as "command not found".
>
>
How about:

Recovery will abort and the server will not start up upon any of the
following:
the shell is unable to execute the command (due to it not being found or
executable),
the command returns an exit status greater than 125, or a non-SIGTERM signal
terminates the shell process. SIGTERM allows a clean shutdown to happen,
if there is one.

Mostly just changing the order a bit but goes from most immediate when
making a change (bad command written into the GUC) to least immediate or
surprising (SIGTERM). The other two flow from there.

David J.