| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, zxwsbg12138(at)gmail(dot)com, david(dot)zhang(at)highgo(dot)ca |
| Subject: | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
| Date: | 2023-11-13 23:41:44 |
| Message-ID: | 20231113234144.7j7ezotvfkwgpdd2@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-11-13 23:55:59 | Re: Why do indexes and sorts use the database collation? |
| Previous Message | Andres Freund | 2023-11-13 23:38:05 | Re: Why do indexes and sorts use the database collation? |