public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: David Steele <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: The danger of deleting backup_label
Date: Thu, 12 Oct 2023 07:22:09 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: The danger of deleting backup_label
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox