Re: CRC was: Re: beta testing version - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CRC was: Re: beta testing version
Date
Msg-id 17295.976224900@sss.pgh.pa.us
Whole thread Raw
In response to RE: CRC was: Re: beta testing version  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses Re: CRC was: Re: beta testing version  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> I would strongly suggest to use strong hashes like RIPEMD or
>> MD5 instead of CRC-32 and the like.

> Other opinions? Also, we shouldn't forget licence issues.

I agree with whoever commented that crypto hashes are silly for this
application.  A 64-bit CRC *might* be enough stronger than a 32-bit
CRC to be worth the extra calculation, but frankly I doubt that too.

Remember that we are already sitting atop hardware that's really pretty
reliable, despite the carping that's been going on in this thread.  All
that we have to do is detect the infrequent case where a block of data
didn't get written due to system failure.  It's wildly pessimistic to
think that we might get called on to do so as much as once a day (if
you are trying to run a reliable database, and are suffering power
failures once a day, and haven't bought a UPS, you're a lost cause).
A 32-bit CRC will fail to detect such an error with a probability of
about 1 in 2^32.  So, a 32-bit CRC will have an MBTF of 2^32 days, or
11 million years, on the wildly pessimistic side --- real installations
probably 100 times better.  That's plenty for me, and improving the odds
to 2^64 or 2^128 is not worth any slowdown IMHO.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Switch pg_ctl's default about waiting?
Next
From: Tom Lane
Date:
Subject: Re: v7.1 beta 1 ...packaged, finally ...