On Sat, Nov 13, 2021 at 6:45 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.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.
