Re: restore_command return code behaviour

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Jean-Christophe Arnu <jcarnu(at)gmail(dot)com>
Cc: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: restore_command return code behaviour
Date: 2025-07-28 21:21:44
Message-ID: CAOYmi+nYMJCbeQpTtE2BsdJr=28SLoOvKpk6uajYoHtSvnOD-g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

WDYT?
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-28 21:25:58 Re: Making pgfdw_report_error statically analyzable
Previous Message Álvaro Herrera 2025-07-28 21:13:44 Re: refactor backend type lists