Re: recovery getting interrupted is not so unusual as it used to be
От | Robert Haas |
---|---|
Тема | Re: recovery getting interrupted is not so unusual as it used to be |
Дата | |
Msg-id | AANLkTilaHLAxaZSDCH0N60O78HgkkR2R53Td07dpkLB9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: recovery getting interrupted is not so unusual as it used to be (Florian Pflug <fgp@phlo.org>) |
Ответы |
Re: recovery getting interrupted is not so unusual as it used to be
|
Список | pgsql-hackers |
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug <fgp@phlo.org> wrote: > On Jun 3, 2010, at 0:58 , Robert Haas wrote: >> But maybe the message isn't right the first time either. After all >> the point of having a write-ahead log in the first place is that we >> should be able to prevent corruption in the event of an unexpected >> shutdown. Maybe the right thing to do is to forget about adding a new >> state and just remove or change the errhint from these messages: > > You've fallen prey to a (very common) miss-interpration of this message. It is not about corruption *caused* by a crashduring recovery, it's about corruption *causing* the crash. > > I'm not in favor of getting rid of that message entirely, since produces a worthwhile hint if the crash was really causedby corrupt data. But it desperately needs a better wording that makes cause and effect perfectly clear. That even youmiss-read it conclusively proves that. > > How about > "If this has happened repeatedly and without manual intervention, it was probably caused by corrupted data and you mayneed to restore from backup" > for the crash recovery case and > "If this has happened repeatedly and without manual intervention, it was probably caused by corrupted data and you mayneed to choose an earlier recovery target" > for the PITR case. Oh. Well, if that's the case, then I guess I lean toward applying the patch as-is. Then there's no need for the caveat "and without manual intervention". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: