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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: robertmhaas@gmail.com, david@pgmasters.net, pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca, andres@anarazel.de
Date: 2023-11-06T07:05:56Z
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 02, 2023 at 11:03:35AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 1 Nov 2023 08:39:17 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
>> See in StartupXLOG(), around the comment "complain if we did not roll
>> forward far enough to reach".  This complains if archive recovery has
>> been requested *or* if we retrieved a backup end LSN from the
>> backup_label.
> 
> Please note that backupStartPoint is not reset even when reaching the
> backup end point during crash recovery. If backup_label enforces
> archive recovery, I think this point won't be an issue as you
> mentioned. For the record, my earlier proposal aimed to detect
> reaching the end point even during crash recovery.

Good point.  Not doing ReachedEndOfBackup() at the end of crash
recovery feels inconsistent, especially since we care about some of
these fields in this case.

If a .signal file is required when we read a backup_label, yes that
would not be a problem because we'd always link backupEndPoint's
destiny with a requested archive recovery, but there seem to be little
love for enforcing that based on the feedback of this thread, so.. 
--
Michael