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

From Martijn van Oosterhout
Subject Re: Block-level CRC checks
Date
Msg-id 20081113221032.GB23571@svana.org
Whole thread Raw
In response to Re: Block-level CRC checks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Block-level CRC checks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 13, 2008 at 01:45:52PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > I'm still testing this; please beware that this likely has an even
> > higher bug density than my regular patches (and some debugging printouts
> > as well).
>
> This seems impossibly fragile ... and the non-modular assumptions about
> what is in a disk page aren't even the worst part :-(.  The worst part
> is the race conditions.

Actually, the real problem to me seems to be that to check the checksum
when you read the page in, you need to look at the contents of the page
and "assume" some of the values in there are correct, before you can
even calculate the checksum. If the page really is corrupted, chances
are the item pointers are going to be bogus, but you need to read them
to calculate the checksum...

Double-buffering allows you to simply checksum the whole page, so
creating a COMP_CRC32_WITH_COPY() macro would do it. Just allocate a
block on the stack, copy/checksum it there, do the write() syscall and
forget it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: auto_explain contrib moudle
Next
From: Greg Smith
Date:
Subject: Re: Simple postgresql.conf wizard