Re: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER

On Fri, Jan 21, 2022 at 8:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Fri, Jan 21, 2022 at 4:20 AM B Ganesh Kishan <bkishan(at)commvault(dot)com>
> > wrote:
> >> The problem is that we are providing a time target that Postgres does not
> >> know how to reach. This is because there are no transactions in between the
> >> backups.
>
> > I don't quite follow the overall situation but given your observation and
> > apparent acceptance of the pre-v13 behavior just don't specify a restore
> > point and let WAL replay everything.
>
> Yeah. If I'm understanding the situation, when you specify a target time
> that is later than the last transaction available from WAL, older versions
> silently assumed that stopping with the last available transaction is OK.
> Newer ones complain because it's not clear whether that's OK --- in
> particular, there's no good way to be sure that no WAL is missing.
>
> On the whole I think that's a good change. I can sympathize with the
> complaint that it creates additional complexity for restore scripts,
> but I'm a little dubious that this is something you'd be wanting to
> script anyway.

This reminds me of the thread [1], where the proposal was to allow
users to choose what should happen in this situation. Basically, a GUC
that takes us to the old behavior i.e. not fail FATALly but emit a
warning and continue.

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

Regards,
Bharath Rupireddy.