Re: The danger of deleting backup_label

On 10/19/23 10:56, Robert Haas wrote:
> On Thu, Oct 19, 2023 at 10:43 AM David Steele <david@pgmasters.net> wrote:
>> 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.
> 
> I mean, writing those tiny little files locally and then uploading
> them should be fine in a case like that. It still reduces the surface
> for mistakes. And you could also have --backup-label='| whatever' or
> something if you wanted. The point is that right now we're asking
> people to pull this information out of a query result, and that means
> people are trying to do it by calling out to psql, and that is a GREAT
> way to screw up the escaping or the newlines or whatever. I don't
> think the mistakes people are making here are being made by people
> using Perl and DBD::Pg, or Python and psycopg2, or C and libpq.
> They're being made by people who are trying to shell script their way
> through it, which entails using psql, which makes screwing it up a
> breeze.

OK, I see what you mean and I agree. Better documentation might be the 
answer here, but I doubt that psql is a good tool for starting/stopping 
backup and not sure we want to encourage it.

Regards,
-David