On Tue, Oct 10, 2023 at 05:06:45PM -0400, David Steele wrote: > That fails because there is a check to make sure the checkpoint is valid > when pg_control is loaded. Another possibility is to use a special LSN like > we use for unlogged tables. Anything >= 24 and < WAL segment size will work > fine.
Do we have any reason to do that in the presence of a backup_label file anyway? We'll know the LSN of the checkpoint based on what the base backup wants us to use. Using a fake-still-rather-valid value for the LSN in the control file to bypass this check does not address the issue you are pointing at: it is just avoiding this check. A reasonable answer would be, IMO, to just not do this check at all based on the control file in this case. >> If the contents of the control file are tweaked before sending it >> through a BASE_BACKUP, it would cover more than just pg_basebackup. >> Switching the way the control file is sent with new contents in >> sendFileWithContent() rather than sendFile() would be one way, for >> instance.. > > Good point, and that makes this even more compelling. If we include > pg_control into backup_label then there is no need to modify pg_control (as > above) -- we can just exclude it from the backup entirely. That will > certainly require some rejigging in recovery but seems worth it for backup > solutions that can't easily modify pg_control. The C-based solutions can do > this pretty easily but it is a pretty high bar for anyone else. I have little idea about that, but I guess that you are referring to backrest here. -- Michael
signature.asc
Description: PGP signature
