restore-command error handling

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.