On Mon, Nov 20, 2023 at 12:54 PM David Steele <da...@pgmasters.net> wrote: > Another thing we could do is explicitly error if we see backup_label in > PGDATA during recovery. That's just a few lines of code so would not be > a big deal to maintain. This error would only be visible on restore, so > it presumes that backup software is being tested.
I think that if we do decide to adopt this proposal, that would be a smart precaution. > A little hard to add to the tests, I think, since they are purely > informational, i.e. not pushed up by the parser. Maybe we could just > grep for the fields? Hmm. Or should they be pushed up by the parser? > I think these fields would be handled the same as the rest of the fields > in backup_label: returned from pg_backup_stop() and also stored in > backup_manifest. Third-party software can do as they like with them and > pg_combinebackup can just read from backup_manifest. I think that would be a bad plan, because this is critical information, and a backup manifest is not a thing that you're required to have. It's not a natural fit at all. We don't want to create a situation where if you nuke the backup_manifest then the server forgets that what it has is an incremental backup rather than a usable data directory. > We absolutely need more people to look at this and sign off. I'm glad > they have not so far because it has allowed time to whack the patch > around and get it into better shape. Cool. -- Robert Haas EDB: http://www.enterprisedb.com
