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.
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" |