On Wednesday, October 18, 2023, David Steele <da...@pgmasters.net> wrote:
> On 10/18/23 08:39, Robert Haas wrote: > >> On Tue, Oct 17, 2023 at 4:17 PM David Steele <da...@pgmasters.net> wrote: >> >>> Given that the above can't be back patched, I'm thinking we don't need >>> backup_label at all going forward. We just write the values we need for >>> recovery into pg_control and return *that* from pg_backup_stop() and >>> tell the user to store it with their backup. We already have "These >>> files are vital to the backup working and must be written byte for byte >>> without modification, which may require opening the file in binary >>> mode." in the documentation so dealing with pg_control should not be a >>> problem. pg_control also has a CRC so we will know if it gets munged. >>> >> >> Yeah, I was thinking about this kind of idea, too. I think it might be >> a good idea, although I'm not completely certain about that, either. >> > > <snip> > > First, anything that is stored in the backup_label but not the control >> file has to (a) move into the control file, >> > > I'd rather avoid this. > > If we are OK outputting custom pg_control file content from pg_backup_end to govern this then I’d probably just include “tablespace_map_required=true|false” and “backup_label_required=true” lines in it and leave everything else mostly the same, including the name. In order for a server with those lines in its pg_control to boot it requires that a signal file be present along with any of the named files where *_required is true. Upon successful completion those lines are removed from pg_control. It seem unnecessary to move any and all relevant content into pg_control; just a flag to ensure that those files that are needed a present in the backup directory and whatever validation of those files is needed to ensure they provide sufficient data. If the user removes those files without a backup the server is not going to start unless they make further obvious attempts to circumvent the design. Manually editing pg_comtrol being obvious circumventing. This would seem to be a compatible change. If you fail to use the pg_control from pg_backup_stop you don’t get the safeguard but everything still works. Do we really believe we need to break/force-upgrade tooling to use this new procedure? Depending on the answer to the torn pg_comtrol file problem which may indeed warrant such breakage. David J.
