Re: Page Checksums - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Page Checksums
Date
Msg-id CAFNqd5WxiHtoF1DpdJ+nGzi=UXdsb0jXA90Jt2doX4aH5doArQ@mail.gmail.com
Whole thread Raw
In response to Re: Page Checksums  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Page Checksums  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Page Checksums  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Dec 20, 2011 at 8:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 2:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> I was thinking that we would warn when such was found, set hint bits
>> as needed, and rewrite with the new CRC.  In the unlikely event that
>> it was a torn hint-bit-only page update, it would be a warning about
>> something which is a benign side-effect of the OS or hardware crash.
>
> But that's terrible.  Surely you don't want to tell people:
>
> WARNING:  Your database is corrupted, or maybe not.  But don't worry,
> I modified the data block so that you won't get this warning again.
>
> OK, I guess I'm not sure that you don't want to tell people that.  But
> *I* don't!

This seems to be a frequent problem with this whole "doing CRCs on pages" thing.

It's not evident which problems will be "real" ones.  And in such
cases, is the answer to turf the database and recover from backup,
because of a single busted page?  For a big database, I'm not sure
that's less scary than the possibility of one page having a
corruption.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Simon Riggs
Date:
Subject: Re: Pause at end of recovery