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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
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:31:34
Message-ID: AANLkTilaHLAxaZSDCH0N60O78HgkkR2R53Td07dpkLB9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug <fgp(at)phlo(dot)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".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2010-06-03 01:33:50 current value support
Previous Message Takahiro Itagaki 2010-06-03 01:07:53 Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names