From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(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 02:59:52 |
Message-ID: | CALj2ACVCrA9Wv4CO4iMfXfSEPGDqArPr1iSscM2H6fUe4TJC6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 12, 2021 at 4:09 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Fri, Nov 12, 2021 at 6:14 PM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > Currently, the server shuts down with a FATAL error (added by commit
> > [1]) when the recovery target isn't reached. This can cause a server
> > availability problem, especially in case of disaster recovery (geo
> > restores) where the primary was down and the user is doing a PITR on a
> > server lying in another region where it had missed to receive few of
> > the last WAL files required to reach the recovery target. In this
> > case, users might want the server to be available rather than a no
> > server. With the commit [1], there's no way to achieve what users
> > wanted.
>
> if users don't mind if the recovery target is reached or not isn't it
> better to simply don't specify a target and let the recovery go as far
> as possible?
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.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-11-13 03:00:10 | Re: Logical Replication - improve error message while adding tables to the publication in check_publication_add_relation |
Previous Message | Zhihong Yu | 2021-11-13 02:23:52 | Re: support for MERGE |