On 10/17/23 22:13, Kyotaro Horiguchi wrote:
> At Tue, 17 Oct 2023 16:16:42 -0400, David Steele <david@pgmasters.net> 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