On Thu, Sep 19, 2019 at 11:06 PM David Steele <da...@pgmasters.net> wrote: > > I don't think it's a good idea to duplicate the information that's > > already in the backup_label. Storing two copies of the same > > information is just an invitation to having to worry about what > > happens if they don't agree. > > OK, but now we have backup_label, tablespace_map, > XXXXXXXXXXXXXXXXXXXXXXXX.XXXXXXXX.backup (in the WAL) and now perhaps a > backup.manifest file. I feel like we may be drowning in backup info files.
I agree! I'm not sure what to do about it, though. The information that is present in the tablespace_map file could have been stored in the backup_label file, I think, and that would have made sense, because both files are serving a very similar purpose: they tell the server that it needs to do some non-standard stuff when it starts up, and they give it instructions for what those things are. And, as a secondary purpose, humans or third-party tools can read them and use that information for whatever purpose they wish. The proposed backup_manifest file is a little different. I don't think that anyone is proposing that the server should read that file: it is there solely for the purpose of helping our own tools or third-party tools or human beings who are, uh, acting like tools.[1] We're also proposing to put it in a different place: the backup_label goes into one of the tar files, but the backup_manifest would sit outside of any tar file. If we were designing this from scratch, maybe we'd roll all of this into one file that serves as backup manifest, tablespace map, backup label, and backup history file, but then again, maybe separating the instructions-to-the-server part from the backup-integrity-checking part makes sense. At any rate, even if we knew for sure that's the direction we wanted to go, getting there from here looks a bit rough. If we just add a backup manifest, people who don't care can mostly ignore it and then should be mostly fine. If we start trying to create the one backup information system to rule them all, we're going to break people's tools. Maybe that's worth doing someday, but the paint isn't even dry on removing recovery.conf yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] There are a surprising number of installations where, in effect, the DBA is the backup-and-restore tool, performing all the steps by hand and hoping not to mess any of them up. The fact that nearly every PostgreSQL company offers tools to make this easier does not seem to have done a whole lot to diminish the number of people using ad-hoc solutions.
