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

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>

To: michael@paquier.xyz

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-02T02:03:35Z

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 →

Delay recovery mode LOG after reading backup_label and/or checkpoint record
- dc5bd3889437 17.0 landed
Mention standby.signal in FATALs for checkpoint record missing at recovery
- 1ffdc03c21ae 17.0 landed
XLOG file archiving and point-in-time recovery. There are still some
- 66ec2db72840 8.0.0 cited

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.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center