Re: Page Checksums

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Smith" <greg(at)2ndQuadrant(dot)com>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page Checksums
Date: 2011-12-21 15:21:53
Message-ID: 4EF1A5310200002500043F37@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-21 15:24:29 Re: CLOG contention
Previous Message Stephen Frost 2011-12-21 15:19:10 Re: Page Checksums