On 6/30/20 6:13 PM, Stephen Frost wrote:
Greetings,
* David Steele (da...@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
da...@pgmasters.net
