Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
От | Andres Freund |
---|---|
Тема | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
Дата | |
Msg-id | 20231113234144.7j7ezotvfkwgpdd2@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
|
Список | 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 по дате отправления: