Re: The danger of deleting backup_label

On Wednesday, October 18, 2023, David Steele <david(at)pgmasters(dot)net> wrote:

> On 10/18/23 08:39, Robert Haas wrote:
>
>> On Tue, Oct 17, 2023 at 4:17 PM David Steele <david(at)pgmasters(dot)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.