Re: restore_command return code behaviour - Mailing list pgsql-hackers

From Jean-Christophe Arnu
Subject Re: restore_command return code behaviour
Date
Msg-id CAHZmTm1QqTC+1PLhuZvi6tfbioPv-TarMsS_hkgL6P+WosOhTQ@mail.gmail.com
Whole thread Raw
In response to Re: restore_command return code behaviour  (Jacob Champion <jacob.champion@enterprisedb.com>)
List 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Convert varatt.h macros to static inline functions
Next
From: Noah Misch
Date:
Subject: Re: Test instability when pg_dump orders by OID