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