Re: Block-level CRC checks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Block-level CRC checks
Date
Msg-id 4807.1259692881@sss.pgh.pa.us
Whole thread Raw
In response to Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Block-level CRC checks  (Greg Stark <gsstark@mit.edu>)
Re: Block-level CRC checks  (Josh Berkus <josh@agliodbs.com>)
Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, here is another idea, maybe crazy:

> When we read in a page that has an invalid CRC, we check the page to see
> which hint bits are _not_ set, and we try setting them to see if can get
> a matching CRC.  If there no missing hint bits and the CRC doesn't
> match, we know the page is corrupt.  If two hint bits are missing, we
> can try setting one and both of them and see if can get a matching CRC. 
> If we can, the page is OK, if not, it is corrupt.

> Now if 32 hint bits are missing, but could be based on transaction
> status, then we would need 2^32 possible hint bit combinations, so we
> can't do the test and we just assume the page is valid.

A typical page is going to have something like 100 tuples, so
potentially 2^400 combinations to try.  I don't see this being
realistic from that standpoint.  What's much worse is that to even
find the potentially missing hint bits, you need to make very strong
assumptions about the validity of the rest of the page.

The suggestions that were made upthread about moving the hint bits
could resolve the second objection, but once you do that you might
as well just exclude them from the CRC and eliminate the guessing.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [CORE] EOL for 7.4?
Next
From: Tom Lane
Date:
Subject: Re: Block-level CRC checks