Greg Stark wrote:
> On Tue, Dec 1, 2009 at 6:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
>
> Unfortunately you would also have to try *unsetting* every hint bit as
> well since the updated hint bits might have made it to disk but not
> the CRC leaving the old CRC for the block with the unset bits.
>
> I actually independently had the same thought today that Simon had of
> moving the hint bits to the line pointer. We can obtain more free bits
> in the line pointers by dividing the item offsets and sizes by
> maxalign if we need it. That should give at least 4 spare bits which
> is all we need for the four VALID/INVALID hint bits.
>
> It should be relatively cheap to skip the hint bits in the line
> pointers since they'll be the same bits of every 16-bit value for a
> whole range. Alternatively we could just CRC the tuples and assume a
> corrupted line pointer will show itself quickly. That would actually
> make it faster than a straight CRC of the whole block -- making
> lemonade out of lemons as it were.
Yea, I am thinking we would have to have the hint bits in the line
pointers --- if not, we would have to reserve a lot of free space to
hold the maximum number of tuple hint bits --- seems like a waste.
I also like the idea that we don't need to CRC check the line pointers
because any corruption there is going to appear immediately. However,
the bad news is that we wouldn't find the corruption until we try to
access bad data and might crash.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +