Re: restore_command return code behaviour

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=412036c22d6a605340dbe397da1fb12fccd3897f#n254

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

Thanks,
--Jacob