On Mon, Jul 28, 2025 at 2:22 PM Jacob Champion < jacob.champ...@enterprisedb.com> wrote:
> On Mon, Jul 28, 2025 at 1:58 PM Jean-Christophe Arnu <jca...@gmail.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.
