Re: The danger of deleting backup_label

On 10/19/23 10:24, Robert Haas wrote:
> On Wed, Oct 18, 2023 at 7:15 PM David Steele <david@pgmasters.net> wrote:
>>> (b) be stored someplace
>>> else,
>>
>> I don't think the additional fields *need* to be stored anywhere at all,
>> at least not by us. We can provide them as output from pg_backup_stop()
>> and the caller can do as they please. None of those fields are part of
>> the restore process.
> 
> Not sure which fields we're talking about here. I agree that if
> they're not really needed, we can return them and the user can keep
> them or discard them as they wish. But in that case you might also ask
> why bother even returning them.

I'm specifically talking about START TIME and LABEL. They are currently 
stored in backup_label but not used for recovery. START TIMELINE is also 
not used, except as a cross check against START WAL LOCATION.

I'd still like to see most or all of these fields exposed through 
pg_backup_stop(). The user can choose to store them or not, but none of 
them will be required for recovery.

>>> pg_llbackup -d $CONNTR --backup-label=PATH --tablespace-map=PATH
>>> --copy-data-directory=SHELLCOMMAND
>>>
>> I think in most cases where this would be useful the user should just be
>> using pg_basebackup. If the backup is trying to use snapshots, then
>> backup_label needs to be stored outside the snapshot and we won't be
>> able to easily help.
> 
> Right, the idea of the above was that you would specify paths for the
> backup label and the tablespace map that were outside of the snapshot
> directory in that kind of case. But you couldn't screw up the line
> endings or whatever because pg_llbackup would take care of that aspect
> of it for you.

What I meant here (but said badly) is that in the case of snapshot 
backups, the backup_label and tablespace_map will likely need to be 
stored somewhere off the server since they can't be part of the 
snapshot, perhaps in a key store. In that case the backup software would 
still need to read the files from wherever we stored then and correctly 
handle them when storing elsewhere. If you were moving the files to say, 
S3, a similar thing needs to happen. In general, I think a locally 
mounted filesystem is very unlikely to be the final destination for 
these files, and if it is then probably pg_basebackup is your friend.

Regards,
-David