Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, arorasam(at)gmail(dot)com
Subject: Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"
Date: 2021-11-12 10:17:46
Message-ID: CALj2ACX3qsz-JcekUsw06uQBCEZD7L0DKY02vk=Y7nyPd6W4fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 23, 2021 at 1:46 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> What do you want to do after the timeout happens? If you want to issue
> a WARNING instead of failing outright, perhaps that makes sense for
> exploratory PITR cases. That could be a simple boolean GUC without
> needing to introduce the timeout logic into the server.

Thanks Jeff. I posted the patch in a separate thread[1] for new GUC
(WARN + promotion or shutdown with FATAL error) in case the recovery
target isn't reached.

[1] - https://www.postgresql.org/message-id/flat/CALj2ACWR4iaph7AWCr5-V9dXqpf2p5B%3D3fTyvLfL8VD_E%2Bx0tA%40mail.gmail.com.

Regards,
Bharath Rupireddy.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2021-11-12 10:19:34 Re: row filtering for logical replication
Previous Message Bharath Rupireddy 2021-11-12 10:14:00 Allow users to choose what happens when recovery target is not reached