Le lun. 28 juil. 2025 à 20:15, Jacob Champion <
jacob.champ...@enterprisedb.com> a écrit :

> I agree that reusing archive_command's wording is probably the way to
> go. I think archive_cleanup_command and recovery_end_command have the
> same issue; opinions on changing those as well?
>

I agree, we could include both of those  in the  fix. But let's refine the
wording.


> Nitpick mode: I think the current wording for archive_command could be
> misleading.
>
> > an error by the shell with an exit status greater than 125 (such as
> command not found)
>
> The phrase "by the shell" is not really true here (that's kind of the
> point of the thread, I'd argue) and I'm wondering if we should move
> that to the parenthetical. But I don't like any of my draft ideas so
> far, and I don't want to get in the way of a small improvement by
> demanding perfection.
>

English is not my native language but let's try some wordings:

Proposals (scheme):

An exception is that if the command was terminated by a signal (other
than SIGTERM which is used as part of a database server shutdown)
or a command returned with an exit code greater than 125, or  an error by
the shell
(such as command not found), then recovery will abort
and the server will not start up.

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


-- 
Jean-Christophe Arnu

Reply via email to