Re: Page Checksums - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Page Checksums
Date
Msg-id 4EF1A5310200002500043F37@gw.wicourts.gov
Whole thread Raw
In response to Re: Page Checksums  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Page Checksums  (Andres Freund <andres@anarazel.de>)
Re: Page Checksums  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Greg Smith <greg@2ndQuadrant.com> wrote:
>>  Some people think I border on the paranoid on this issue.
> 
> Those people are also out to get you, just like the hardware.
Hah!  I *knew* it!
>> Are you arguing that autovacuum should be disabled after crash
>> recovery?  I guess if you are arguing that a database VACUUM
>> might destroy recoverable data when hardware starts to fail, I
>> can't argue.
> 
> A CRC failure suggests to me a significantly higher possibility
> of hardware likely to lead to more corruption than a normal crash
> does though.
Yeah, the discussion has me coming around to the point of view
advocated by Andres: that it should be treated the same as corrupt
pages detected through other means.  But that can only be done if
you eliminate false positives from hint-bit-only updates.  Without
some way to handle that, I guess that means the idea is dead.
Also, I'm not sure that our shop would want to dedicate any space
per page for this, since we're comparing between databases to ensure
that values actually match, row by row, during idle time.  A CRC or
checksum is a lot weaker than that.  I can see where it would be
very valuable where more rigorous methods aren't in use; but it
would really be just extra overhead with little or no benefit for
most of our database clusters.
-Kevin


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Page Checksums
Next
From: Robert Haas
Date:
Subject: Re: CLOG contention