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

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.

[1] https://www.postgresql.org/message-id/CALj2ACVnCsNyJTG_75%2B5Us2evfsLYz5CEhmCV4qH%3DVPa0kWOvw%40mail.gmail.com

Regards,
Bharath Rupireddy.

In response to

Browse pgsql-hackers by date

  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