Re: recovery getting interrupted is not so unusual as it used to be

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: recovery getting interrupted is not so unusual as it used to be
Date: 2010-06-03 01:07:49
Message-ID: 72DFECBE-419D-413B-985F-7DF29FB92573@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Takahiro Itagaki 2010-06-03 01:07:53 Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Previous Message Bruce Momjian 2010-06-03 01:06:12 Re: ALTER TABLE .... make constraint DEFERRABLE