On Jun 3, 2010, at 3:31 , Robert Haas wrote: > On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug <f...@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 crash during 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 caused by corrupt data. But it >> desperately needs a better wording that makes cause and effect perfectly >> clear. That even you miss-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 may need 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 may need 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".
That still leaves the messages awfully ambiguous concerning the cause (data corruption) and the effect (crash during recovery). How about "If this has occurred more than once, it is probably caused by corrupt data and you have to use the latest backup for recovery" for the crash recovery case and "If this has occurred more than once, it is probably caused by corrupt data and you have to choose an earlier recovery target" for the PITR case. I don't see why currently only the PITR-case includes the "more than once" clause. Its probably supposed to prevent unnecessarily alarming the user if the "crash" was in fact a stray SIGKILL or an out-of-memory condition, which seems equally likely in both cases. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
