Re: CRC was: Re: beta testing version

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: "'Horst Herb'" <hherb(at)malleenet(dot)net(dot)au>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: CRC was: Re: beta testing version
Date: 2000-12-07 21:35:00
Message-ID: 17295.976224900@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-12-07 21:35:11 Re: v7.1 beta 1 ...packaged, finally ...
Previous Message Jonathan Ellis 2000-12-07 21:30:24 Re: Oracle-compatible lpad/rpad behavior