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

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allow users to choose what happens when recovery target is not reached
Date: 2021-11-13 04:15:11
Message-ID: CAOBaU_ZpL7ErqizdcZEyJ_fpR9ubFNAZ7kMWcxZdk7sS8T=X_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 13, 2021 at 11:00 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-11-13 04:17:58 Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)
Previous Message Japin Li 2021-11-13 03:31:57 Invalid Unicode escape value at or near "\u0000"