public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Steele <[email protected]>
To: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: The danger of deleting backup_label
Date: Wed, 18 Oct 2023 10:38:39 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 10/17/23 22:13, Kyotaro Horiguchi wrote:
> At Tue, 17 Oct 2023 16:16:42 -0400, David Steele <[email protected]> wrote in
>> 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.
> 
> I'm somewhat perplexed regarding the objective of this thread.
> 
> This thread began with the intent of preventing users from removing
> the backup_label from a backup. At the beginning, the proposal aimed
> to achieve this by injecting an invalid value to pg_control file
> located in the generated backup. However, this (and previous) proposal
> seems to deviate from that initial objective. It now eliminates the
> need to be concerned about the pg_control version that is coped into
> the generated backup. However, if someone removes the backup_label
> from a backup, the initial concerns could still surface.

Yeah, the discussion has moved around quite a bit, but the goal remains 
the same, to make Postgres error when it does not have the information 
it needs to proceed with recovery. Right now if you delete backup_label 
recovery appears to complete successfully, silently corrupting the database.

In the proposal as it stands now there would be no backup_label at all, 
so no danger of removing it.

We have also gotten a bit sidetracked by our hope to use this proposal 
to address torn reads of pg_control during the backup, at least in HEAD.

Regards,
-David

view thread (18+ messages)

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], [email protected], [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