Re: CRC was: Re: beta testing version

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CRC was: Re: beta testing version
Дата
Msg-id 17295.976224900@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: CRC was: Re: beta testing version  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Ответы Re: CRC was: Re: beta testing version  (ncm@zembu.com (Nathan Myers))
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Switch pg_ctl's default about waiting?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: v7.1 beta 1 ...packaged, finally ...