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