Re: Allow users to choose what happens when recovery target is not reached

Firstly, the proposed patch adds no new behaviour as such, it just

gives the ability that is existing today on v12 and below (prior to

commit dc78866 which went into v13 and later).

I think performing PITR is the user's wish - whether the primary is

available or not, it is completely the user's choice. The user might

start the PITR, when the primary is available, thinking that it sends

all the WAL files required for achieving recovery target. But imagine

a disaster happens and the primary server crashes, say the recovery

has replayed a huge bunch of WAL records (a TB may be), and the

primary failed without sending the last one or few WAL files, should

the PITR target server be failing this case after replaying a huge

bunch of WAL records? The user might want the target server to be

available instead of FATALly shutting down. This is the exact problem

the proposed patch is trying to solve.

As I said earlier, the behaviour is not too dangerous as it is not

something new that the patch is proposing, it exists today in v12 and

below. In fact, it gives a way out of a "dangerous situation" if the

user ever gets stuck in it without wasting recovery cycles and compute

resources, by quickly getting the database to be available(of course,

the responsibility lies with the user to deal with the missing WAL

files).