Re: Return pg_control from pg_backup_stop().

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