Re: Use of backup_label not noted in log
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org, Michael Paquier <michael.paquier@gmail.com>, David Steele <david@pgmasters.net>
Date: 2023-11-20T18:24:42Z
Lists: pgsql-hackers
Hi, On 2023-11-20 11:24:25 -0500, Robert Haas wrote: > I do also think it is worth considering how this proposal interacts > with the proposal to remove backup_label. If that proposal goes > through, then this proposal is obsolete, I believe. I think it's the opposite, if anything. Today you can at least tell there was use of a backup_label by looking for backup_label.old and you can verify fairly easily in a restore script that backup_label is present. If we "just" use pg_control, neither of those is as easy. I.e. log messages would be more important, not less. Depending on how things work out, we might need to reformulate and/or move them a bit, but that doesn't seem like a big deal. > But if this is a good idea, does that mean that's not a good idea? Or would > we try to make the pg_control which that patch would drop in place have some > internal difference which we could use to drive a similar log message? I think we absolutely have to. If there's no way to tell whether an "external" pg_backup_start/stop() procedure actually used the proper pg_control, it'd make the situation substantially worse compared to today's, already bad, situation. Greetings, Andres Freund
Commits
-
Add more LOG messages when starting and ending recovery from a backup
- 8b34cff3381a 15.6 landed
- edbd1b41ab5b 16.2 landed
- 1d35f705e191 17.0 landed