Horton

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Steele <david@pgmasters.net>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca, Andres Freund <andres@anarazel.de>
Date: 2023-11-09T03:16:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Delay recovery mode LOG after reading backup_label and/or checkpoint record

  2. Mention standby.signal in FATALs for checkpoint record missing at recovery

  3. XLOG file archiving and point-in-time recovery. There are still some

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.

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.
--
Michael