From: | Jean-Christophe Arnu <jcarnu(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-08-03 23:02:56 |
Message-ID: | CAHZmTm1QqTC+1PLhuZvi6tfbioPv-TarMsS_hkgL6P+WosOhTQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
>
> 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.)
>
That's right it has nothing to do with the error message. That proposal was
only intended to help any people with the server behaviour in such cases.
Not everybody reminds its POSIX return codes if not practiced. And it may
be hard (or take long) to understand why the server is stopped with a
simple scp returning 255 in some cases.
Just adding rhe "over 126 return code leads to server stop" (or so) to the
current doc version seems enough to me.
Jean-Christophe Arnu
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2025-08-04 00:03:21 | Re: Test instability when pg_dump orders by OID |
Previous Message | Tom Lane | 2025-08-03 20:20:31 | Re: Convert varatt.h macros to static inline functions |