On Wednesday, July 30, 2025, Jacob Champion <
jacob.champion@enterprisedb.com> wrote:
On Mon, Jul 28, 2025 at 3:38 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Monday, July 28, 2025, Jacob Champion <jacob.champion@enterprisedb.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
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.
