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

From Mark Mielke
Subject Re: Block-level CRC checks
Date
Msg-id 48E3AE4A.6050605@mark.mielke.cc
Whole thread Raw
In response to Re: Block-level CRC checks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote: <blockquote cite="mid:23549.1222876590@sss.pgh.pa.us" type="cite"><pre wrap="">Paul Schlie <a
class="moz-txt-link-rfc2396E"href="mailto:schlie@comcast.net"><schlie@comcast.net></a> writes: </pre><blockquote
type="cite"><prewrap="">- yes, if you're willing to compute true CRC's as opposed to simpler
 
checksums, which may be worth the price if in fact many/most data
check failures are truly caused by single bit errors somewhere in the
chain,   </pre></blockquote><pre wrap="">
FWIW, not one of the corrupted-data problems I've investigated has ever
looked like a single-bit error.  So the theoretical basis for using a
CRC here seems pretty weak.  I doubt we'd even consider automatic repair
attempts anyway. </pre></blockquote><br /> Single bit failures are probably the most common, but they are probably
alreadyhandled by the hardware. I don't think I've ever seen a modern hard drive return a wrong bit - I get short reads
first.By the time somebody notices a problem, it's probably more than a few bits that have accumulated. For example, if
memoryhas a faulty cell in it, it will create a fault a percentage of every time it is accessed. One bit error easily
turnsinto two, three, ... Then there is the fact that no hardware is perfect, and every single component in the
computerhas a chance, however small, of introducing bit errors... :-(<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>

pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Block-level CRC checks
Next
From: Gregory Stark
Date:
Subject: Re: Block-level CRC checks