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

Hello,

Can someone please help here?

Thanks and Regards,
Ganesh Kishan

-----Original Message-----
From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Sent: 27 January 2022 19:47
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>; B Ganesh Kishan <bkishan(at)commvault(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org; Meera Nair <mnair(at)commvault(dot)com>
Subject: Re: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER

External email. Inspect before opening.

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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql.org%2Fmessage-id%2Fflat%2FCALj2ACWR4iaph7AWCr5-V9dXqpf2p5B%253D3fTyvLfL8VD_E%252Bx0tA%2540mail.gmail.com&amp;data=04%7C01%7Cbkishan%40commvault.com%7C9a2731e7ee4a4ddfa02808d9e19fb56a%7C40ed1e38a16e46229d7c45161b6969d5%7C0%7C0%7C637788898326072542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DuJTWKxhxWJkg%2B%2FMNRbK%2B1s9TXTojRPei1cNSDNF5oY%3D&amp;reserved=0

Regards,
Bharath Rupireddy.