Returns error code 74 on WAL fetch when WAL file does not exist

[sebasmannem]

Database name

Postgres

Pull request description

Describe what this PR fix

When running wal-g in restore_command, postgres has 3 ways to handle a exit code:
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

It would be great if wal-g would be able to distinguish between these cases with a proper exit code too.
Mostly it is so, but config errors, tcp errors, dns errors, etc have the same error code as 'archive does not exist (both 1).

This small change will allow wal-g to return exit code 74 when the wal file does not exist.

Please provide steps to reproduce (if it's a bug)

• create a postgres backup with wal archive backups
• restore a file that already exists and print the exit code wal-g wal-fetch 000000010000000300000099 /tmp/000000010000000300000099. It is 1.
• restore a file with missing config: WALG_S3_PREFIX=123 wal-g wal-fetch 000000010000000300000099 /tmp/000000010000000300000099. It is also 1. We should distinguish, but this not different to Postgres either...
• restore a file that does not exist int the backupset wal-g wal-fetch 00000001000000030000009A /tmp/00000001000000030000009Aand print the exit code. It is also 1, but should be distinguishable

Please see #1126 for more info.

Even with this fix, we still need Postgres to act differently too.
We have requested a change but it is not considered by the PG community yet.
For now we could make this work with a bash script:

#!/bin/bash
wal-g wal-fetch "$2" "$3"
RET=$?
if [ $RET -eq 1 ]; then
  # whoops, no good. exit code 254 halts postgres with a FAILURE state
  exit 254
fi
exit $RET

[x4m]

I don’t like that we advise to use shell script on top of WAL-G. WAL-G should be that script. Though, let’s merge, I think it’s still for good :)

[sebasmannem]

Yes.
One of my hesitations too.
It is just nasty that we need to set to 126+ to get the behavior we should have from postgres.
If this works as we hope, I will see if I can expand the solution.

[haslersn]

For PostgreSQL that should be any error code between 126 and 255, which can be achieved with a simple wrapper script.

Where is this documented?

Also, why do we necessarily want to stop PostgreSQL, if the restore_command running wal-g exits with an error? I thought PostgreSQL will next try to restore WAL from the pg_wal directory, then from the primary server, and then from the archive location again. In a cycle.