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. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
