Re: Block-level CRC checks

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Brian Hurt" <bhurt(at)janestcapital(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 22:35:25
Message-ID: 877i8qsk0i.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Dawid Kuroczko" <qnex42(at)gmail(dot)com> writes:

> On Thu, Oct 2, 2008 at 7:42 PM, Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> wrote:
>
> if checksum mismatch {
> flip the hint bits [1]

I did try to make something like that work. But I didn't get anywhere. There
could easily be dozens of bits to flip. The MaxHeapTuplesPerPage is over 200
and you could easily have half of them that don't match the checksum if the
writes happen in 4k chunks. If they happen in 512b chunks then you could have
a lot more. And yes they could easily have all been set at around the same
time because that's often just what a sequential scan does.

And you can't even just set the bits to their "correct" values either before
the checksum or before checking the checksum since the "correct" value changes
over time. By the time you compare the checksum more bits will be settable
than when the page was stored.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-10-02 22:42:59 Re: Transaction Snapshots and Hot Standby
Previous Message Decibel! 2008-10-02 22:23:41 Re: Block-level CRC checks