On 10/28/26 10:48, Heikki Linnakangas wrote:
On 26/10/2026 13:42, David Steele wrote:
On 10/23/26 18:17, Heikki Linnakangas wrote:
On 23/10/2026 15:42, David Steele wrote:
Umm, not new with his patch, but why do we still have that hint to
remove backup_label? Is that ever the right thing to do? Why didn't
we remove that hint when exclusive-mode backups were removed?
Unfortunately I believe there is still a use case for this hint. When
making a backup, e.g. via snapshot, it is still easier to write the
backup_label into PGDATA, make the snapshot, then remove it. If the
cluster crashes before the removal then the answer is to remove the
backup label, just as it was if exclusive backup crashed.
I'm not excited about the above use case but not sure we can discount
it entirely.
If you take an atomic filesystem-level snapshot, restoring it is
equivalent to crash recovery, so you don't need a backup_label to
restore it to a consistent state. There's no need for pg_start_backup()
or a backup_label in that case. Admittedly, a non-atomic snapshot is a
different story.
True, but I recommend *always* using the documented backup procedure,
especially if PITR will be used on restore.
But I don't see how you could do that anyway. The backup_label is
returned by pg_stop_backup(). If the sequence is:
1. pg_start_backup()
2. take filesystem snapshot
3. pg_stop_backup()
there's no way to include the backup_label in the snapshot, because you
don't have it until you call pg_stop_backup().
Oops, yeah, that was an old pattern what was still usable up until PG14
but should no longer be possible.
I searched the thread where we removed exclusive backup and I can't see
any reason why we would have kept it, so it was probably an oversight.
Once Michael and I have resolved the build farm issue with 01 I'll
rebase and make the removal a small patch before adding the pgcontrol
flag -- unless you would prefer a separate thread.
Regards,
-David
