Re: Remove Deprecated Exclusive Backup Mode

On 6/30/20 6:13 PM, Stephen Frost wrote:
> Greetings,
> 
> * David Steele (david@pgmasters.net) wrote:
>> Lastly, there is some concern about getting the backup label too late when
>> doing snapshots or using traditional backup software. It would certainly be
>> possible to return the backup_label and tablespace_map from
>> pg_start_backup() and let the user make the choice about what to do with
>> them. Any of these methods will require some scripting so I don't see why
>> the files couldn't be written as, for example, backup_label.snap and
>> tablespace_map.snap and then renamed by the restore script. The patch does
>> not currently make this change, but it could be added pretty easily if that
>> overcomes this objection.
> 
> Of course, if someone just restored that snapshot without actually
> moving the files into place they'd get a corrupted database without any
> indication of anything being wrong...
> 
> And if we checked for those files on startup and complained about them
> being there (called .snap) then we're back into the "crash during backup
> causes PG to fail to start" situation.
> 
> All of which is, as I recall, is why we have the API we do today.

I'm certainly not proposing that we ignore .snap files (or whatever). 
There are a many ways a restore can be done incorrectly and not be 
detected. The restore script would be responsible for knowing the rules 
and renaming the files or erroring out.

> As such, doing that doesn't strike me as an improvement over using the
> new API and making it abundently clear that it's not so simple as people
> might like to think it is...

Sure, backup is complicated, but I think there's an argument for 
providing the backup_label and tablespace_map files at the beginning of 
the backup since they are available at that point. And maybe put some 
scary language about storing them in PGDATA.

Regards,
-- 
-David
david@pgmasters.net