From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Christopher Kings-Lynne'" <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: AW: beta testing version |
Date: | 2000-12-07 03:03:07 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D31D3@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > CRCs are designed to catch N-bit errors (ie N bits in a row
> with their
> > values flipped). N is (IIRC) the number of bits in the CRC
> minus one.
> > So, a 32-bit CRC can catch all 31-bit errors. That's the
> only guarantee
> > a CRC gives. Everything else has a 1 in 2^32-1 chance of
> producing the
> > same CRC as the original data. That's pretty good odds, but not a
> > guarantee.
>
> You've got a higher chance of undetected hard drive errors,
> memory errors,
> solar flares, etc. than a CRC of that quality failing...
Also, how long is CRC in TCP/IP packages? => there is always
risk that backend will commit not what you sended to it.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2000-12-07 03:09:50 | HeapTuple? |
Previous Message | Christopher Kings-Lynne | 2000-12-07 02:52:30 | RE: AW: beta testing version |