Re: Allow users to choose what happens when recovery target is not reached - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Allow users to choose what happens when recovery target is not reached
Date
Msg-id CAOBaU_ZpL7ErqizdcZEyJ_fpR9ubFNAZ7kMWcxZdk7sS8T=X_A@mail.gmail.com
Whole thread Raw
In response to Re: Allow users to choose what happens when recovery target is not reached  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Allow users to choose what happens when recovery target is not reached
List pgsql-hackers
On Sat, Nov 13, 2021 at 11:00 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Users will always be optimistic and set a recovery target and try to
> reach it, but somehow the few of the WAL files haven't arrived (for
> whatever the reasons) the PITR target server, imagine if their primary
> isn't available too, then with the proposal I made, they can choose to
> have at least an available target server rather than a FATALly failed
> one.

If your primary server isn't available, why would you want a recovery
target in the first place?  I just don't understand in which case
someone would want to setup a recovery target and wouldn't care if the
recovery wasn't reached, especially if it can be off by GB / days of
data.

It seems like it could have the opposite effect of what you want most
of the time.  What if for some reason the restore_command is flawed,
and you end up starting your server because it couldn't restore WAL
that are actually available?  You would have to restart from scratch
and waste more time than if you didn't use this.

It look like what you actually want is some kind of a target window,
but the window you currently propose is a hardcoded (consistency,
given target], and it seems too dangerous to be useful.



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Invalid Unicode escape value at or near "\u0000"
Next
From: Julien Rouhaud
Date:
Subject: Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)