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: | 2022-01-29 15:05:51 |
Message-ID: | CALj2ACX4J+9eQHbGG0mNMrRpwYXWa5VZ1hQMo_fnuB0ceHmmZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 13, 2021 at 6:45 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> 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.
>
> With the GUC proposed, the user can choose what to do in these
> scenarios. The user will be fully aware what she needs when she choose
> to set the new GUC recovery_end_before_target_action to 'promote'
> instead of default 'shutdown'.
Hi Hackers, with a recent bug report [1] in pgsql-bugs, I'm checking
if the proposal here in this thread interests anyone.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2022-01-29 17:12:05 | Re: Multiple Query IDs for a rewritten parse tree |
Previous Message | Fabien COELHO | 2022-01-29 14:40:00 | Re: psql - add SHOW_ALL_RESULTS option |