Re: restore_command return code behaviour

On Wednesday, July 30, 2025, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
wrote:

> On Mon, Jul 28, 2025 at 3:38 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > On Monday, July 28, 2025, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)
> com> wrote:
> >> RestoreArchivedFile() has a special case for SIGTERM, though?
> >
> > I don’t see anything calling out sigterm by name.
>
> It's got a comment explaining the separate behavior, right before the
> call to wait_result_is_signal(rc, SIGTERM):
>
> https://git.postgresql.org/cgit/postgresql.git/tree/src/
> backend/access/transam/xlogarchive.c?id=412036c22d6a605340dbe397da1fb1
> 2fccd3897f#n254
>
>
Oops, I was looking at fe_utils not xlogarchive.

> > I don’t really see a point in describing the special meanings ascribed
> to 126 and 127 here since the error message will handle that should the
> need arise.
>
> I don't think Jean-Christophe's stated problem is with the server's
> error message (Jean-Christophe, please jump in and correct me) -- it's
> in knowing how to design the command so that the system behaves
> correctly. I'm not very excited about removing information at the same
> time that we're solving a lack-of-information problem. (At least not
> without consensus that the information is irrelevant, and personally I
> think the cases described so far in this thread are relevant to people
> writing these commands.)
>

Works for me. I do see the value in pointing out “command could not be
executed” behavior without referring to exit status codes. But it does
make the text longer and maybe we could centralize it somewhere by
leveraging the reference design. But acknowledge that most of them will
not have the knowledge memorized and being a bit more verbose would be a
useful shortcut for them.

David J.