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