| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Jean-Christophe Arnu <jcarnu(at)gmail(dot)com>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: restore_command return code behaviour |
| Date: | 2025-07-28 21:58:08 |
| Message-ID: | CAOYmi+kL2kATavDhJ7dwJpA0vnJjFB+k7XiRqQZLzeTZdTd__w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
> And in any case signals are turned into exit status values anyway so naming them specifically seems redundant.
>
> 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).
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-07-28 22:38:09 | Re: restore_command return code behaviour |
| Previous Message | David G. Johnston | 2025-07-28 21:42:47 | Re: restore_command return code behaviour |