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

Laurenz Albe <laurenz.albe@cybertec.at>

From: Laurenz Albe <laurenz.albe@cybertec.at>

To: Michael Paquier <michael@paquier.xyz>, David Steele <david@pgmasters.net>

Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca

Date: 2023-10-16T15:48:43Z

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

On Mon, 2023-10-16 at 14:54 +0900, Michael Paquier wrote:
> Thanks for the review.  Yes, I am wondering if other people would
> chime in here.  It doesn't feel like this has gathered enough
> opinions.

I don't have strong feelings either way.  If you have backup_label
but no signal file, starting PostgreSQL may succeed (if the WAL
with the checkpoint happens to be in pg_wal) or it may fail with
an error message.  There is no danger of causing damage unless you
remove backup_label, right?

I cannot think of a use case where you use such a configuration on
purpose, and the current error message is more crypric than a plain
"you must have a signal file to start from a backup", so perhaps
your patch is a good idea.

Yours,
Laurenz Albe