>On 16 August 2016 at 09:06, Stephen Frost <sfrost@snowman.net> wrote:
>> From PG's perspective,
>> your restore command has said that all of the WAL has been replayed.
>>
>> If that's not what you want then change your restore command to
>> return an exit code > 125, which tells PG that it's unable to restore
>> that WAL segment.
>
> Ah! Is this documented somewhere?
> if we expect people to use correct exit codes we should document them,
> no?
It seems to be set out clearly in the code comments, but only alluded
to in the "Recovering using a continuous archive backup" doc section.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/transam/xlogarchive.c;h=7afb73579b009444f9b7df658645ea3f2cf5e5f5;hb=958fe549884928cd3bdf009993e9a05df5fd6cee#l270
It looks like the code was put there to cover the case where certain
unanticipated Bad Things happen (a signal, or one of the Single Unix
Spec reserved codes 126 or 127 when the shell couldn't do what you`
asked it to), but not necessarily with an eye to the possibility you
might /want/ to make recovery abort based on a condition your restore
script detects, and that's why the doc only mentions an exception
on termination by a signal or an error by the shell, but doesn't
emphasize how you could do this yourself (by exit 126 or 127, or
sending yourself a signal).
Maybe that is worth a brief mention? It doesn't seem outlandish to me
that a restore script could detect conditions worth stopping recovery
for.
-Chap