Re: Requiring recovery.signal or standby.signal when recovering with a backup_label - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Date
Msg-id 20231113234144.7j7ezotvfkwgpdd2@awork3.anarazel.de
Whole thread Raw
In response to Re: Requiring recovery.signal or standby.signal when recovering with a backup_label  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
List pgsql-hackers
Hi,

On 2023-11-09 12:16:52 +0900, Michael Paquier wrote:
> On Thu, Nov 09, 2023 at 12:04:19PM +0900, Michael Paquier wrote:
> > Sure, sorry for the confusion.  By "we'd do nothing", I mean precirely
> > "to take no specific action related to archive recovery and recovery
> > parameters at the end of recovery", meaning that a combination of
> > backup_label with no signal file would be the same as crash recovery,
> > replaying WAL up to the end of what can be found in pg_wal/, and only
> > that.

I don't think those are equivalent - in the "backup_label with no signal file"
case we start recovery at a different location than the "crash recovery" case
does.


> By being slightly more precise.  I also mean to fail recovery if it is
> not possible to replay up to the end-of-backup LSN marked in the label
> file because we are missing some stuff in pg_wal/, which is something
> that the code is currently able to handle.

"able to handle" as in detect and error out? Because that's the only possible
sane thing to do, correct?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Why do indexes and sorts use the database collation?
Next
From: Jeff Davis
Date:
Subject: Re: Why do indexes and sorts use the database collation?