Hi,
this should probably be for pgsql-hackers, but https://www.postgresql.org/list/ mentioned 'You must try elsewhere first!', and this list was second best... I wanted to point you to this github issue: https://github.com/wal-g/wal-g/issues/1126 Basically, Postgres only knows of 3 types of return codes: 0: No problem, next WAL file... 1 - 125: End of timeline? Ok, lets stop recovery and go online >=126: Ouch, big problem. Better not proceed, but error out with a FAIL instead Looking at https://tldp.org/LDP/abs/html/exitcodes.html exit codes beyond 125 is all OS related. Like 'Permission problem or command is not an executable', or 'Control-C is fatal error signal 2'. I would assume that exit code 78 would be a better choice to distinguish errors for the restore_command which are not os-related, but still would be better ending in 'Ouch, big problem. Better not proceed, but error out with a FAIL instead'. I think I will work on a fix for wal-g to better distinguish in exit codes, but since all I currently can do is exit with a code >= 126, I wanted to bring this to the postgres community too. Furthermore, this is beyond wal-g, basically for everything that runs as a restore_command... Would you consider another exit code to the list so that restore_commands don't need to exit with error codes that where meant to signal OS-level issues? I wanted to end with this quote from the second link I pointed to: Ending a script with exit 127 would certainly cause confusion when troubleshooting (is the error code a "command not found" or a user-defined one?). However, many scripts use an exit 1 as a general bailout-upon-error. Since exit code 1 signifies so many possible errors, it is not particularly useful in debugging. Which to me is not just for 127, but for all exit codes beyond 125... Thanks.
