Re: restore_command return code behaviour

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

> On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > I don’t understand calling out sigterm as an exception, the same
> abort-and-shutdown action happens there too.
>
> RestoreArchivedFile() has a special case for SIGTERM, though?

I don’t see anything calling out sigterm by name. It seems to be handled
the same as any other signal exit and, because of the “true” being passed
into wait_result_is_any_signal, identically to exit statuses 126-127 as
well.

>
> > And in any case signals are turned into exit status values anyway so
> naming them specifically seems redundant.

Ok, yeah, the C API differentiates this reality since an unhandled signal
precludes an exit status from being created. I’m fine with “…unhandled
signals causing command termination, or exit statues > 125, result in abort
and stop”.

> >
> > The “Command not found” error is defined by POSIX as exit status 127
> making its specification redundant with > 125
>
> I don't think either is redundant from the point of view of the
> targeted audience, who may not understand the overlap in the POSIX
> specification. "My command returned", "my command died", and "my
> command never ran" are interesting cases to have to consider (and I
> think it's unfortunate that we can't reliably tell them apart).
>

wait_result_to_str seems to be sufficient. Sure, the command author can
choose to violate conventions, but that’s life.

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.

David J.