RE: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER - Mailing list pgsql-bugs

From B Ganesh Kishan
Subject RE: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER
Date
Msg-id SA1PR19MB50888FF75B7A2F5B769449D6B7259@SA1PR19MB5088.namprd19.prod.outlook.com
Whole thread Raw
In response to Re: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-bugs
Hello,

Can someone please help here?

Thanks and Regards,
Ganesh Kishan

-----Original Message-----
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Sent: 27 January 2022 19:47
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David G. Johnston <david.g.johnston@gmail.com>; B Ganesh Kishan <bkishan@commvault.com>;
pgsql-bugs@lists.postgresql.org;Meera Nair <mnair@commvault.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@sss.pgh.pa.us> wrote:
>
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > On Fri, Jan 21, 2022 at 4:20 AM B Ganesh Kishan
> > <bkishan@commvault.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&data=04%7C01%7Cbkishan%40commvault.com%7C9a2731e7ee4a4ddfa02808d9e19fb56a%7C40ed1e38a16e46229d7c45161b6969d5%7C0%7C0%7C637788898326072542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DuJTWKxhxWJkg%2B%2FMNRbK%2B1s9TXTojRPei1cNSDNF5oY%3D&reserved=0

Regards,
Bharath Rupireddy.



pgsql-bugs by date:

Previous
From: "ideriha.takeshi@fujitsu.com"
Date:
Subject: RE: The follwing error sometimes happened while updating partitioned table using inheritance; ERROR: attribute xxx of type record has wrong type
Next
From: PG Bug reporting form
Date:
Subject: BUG #17389: pg_repack creates race conditions on streaming replicas