Kevin Grittner wrote: >>>> Tom Lane <[EMAIL PROTECTED]> wrote: >> Paul Schlie <[EMAIL PROTECTED]> writes: >>> - 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, >> >> 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. > > +1 > > The only single-bit errors I've seen have been the result of a buggy > driver for a particular model of network card. The problem went away > with the next update of the driver. I've never encountered a > single-bit error in a disk sector.
- although I personally don't see how a buggy driver could ever likely generate single bit errors within the data stored/retrieved, as most typically have no business mucking with data beyond breaking-it-up or collating it into larger chunks typically on octet boundaries, unless implementing a soft usart or something like that for some odd reason. - however regardless, if some form of error detection ends up being implemented, it might be nice to actually log corrupted blocks of data along with their previously computed checksums for subsequent analysis in an effort to ascertain if there's an opportunity to improve its implementation based on this more concrete real-world information. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
