Re: The danger of deleting backup_label - Mailing list pgsql-hackers

From Robert Haas
Subject Re: The danger of deleting backup_label
Date
Msg-id CA+TgmoYYcGC-aErHmYyqggST4Q5SKqeZDxikgg_BTi=3tZGJQw@mail.gmail.com
Whole thread Raw
In response to Re: The danger of deleting backup_label  (David Steele <david@pgmasters.net>)
Responses Re: The danger of deleting backup_label
List pgsql-hackers
On Mon, Oct 16, 2023 at 1:00 PM David Steele <david@pgmasters.net> wrote:
> After some agonizing (we hope) they decide to delete backup_label and,
> wow, it just works! So now they merrily go on their way with a corrupted
> cluster. They also remember for the next time that deleting backup_label
> is definitely a good procedure.
>
> The idea behind this patch is that deleting backup_label would produce a
> hard error because pg_control would be missing as well (if the backup
> software did its job). If both pg_control and backup_label are present
> (but pg_control has not been loaded with the contents of backup_label,
> i.e. it is the running copy from the backup cluster) we can also error.

I mean, I think we're just going in circles, here. I did and do
understand, but I didn't and don't agree. You're hypothesizing a user
who is willing to do ONE thing that they shouldn't do during backup
restoration (namely, remove backup_label) but who won't be willing to
do a SECOND thing that they shouldn't do during backup restoration
(namely, run pg_resetwal). In my experience, users who are willing to
corrupt their database don't typically limit themselves to one bad
decision, and therefore I doubt that this proposal delivers enough
value to justify the complexity.

I understand that you feel differently, and that's fine, but I don't
think our disagreement here stems from me being confused. I just ...
don't agree.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Next
From: Laurenz Albe
Date:
Subject: Re: Improving Physical Backup/Restore within the Low Level API