Re: The danger of deleting backup_label
От | David Steele |
---|---|
Тема | Re: The danger of deleting backup_label |
Дата | |
Msg-id | aa892ab1-48f7-78a2-44b8-76b4495b77d2@pgmasters.net обсуждение исходный текст |
Ответ на | Re: The danger of deleting backup_label (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: The danger of deleting backup_label
|
Список | pgsql-hackers |
On 10/16/23 15:06, Robert Haas wrote: > 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 the first case is much more likely than the second. Your experience may vary. Anyway, I think they are pretty different. Deleting backup label appears to give a perfectly valid restore. Running pg_resetwal is more clearly (I think) the nuclear solution. > 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. Fair enough, we don't agree. Regards, -David
В списке pgsql-hackers по дате отправления: