Re: What exactly is our CRC algorithm? - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: What exactly is our CRC algorithm?
Date
Msg-id 54362F91.4050904@vmware.com
Whole thread Raw
In response to Re: What exactly is our CRC algorithm?  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers
On 10/09/2014 01:23 AM, Gavin Flower wrote:
> On 09/10/14 10:13, Andres Freund wrote:
>> If we're switching to a saner computation, we should imo also switch to
>> a better polynom - CRC-32C has better error detection capabilities than
>> CRC32 and is available in hardware. As we're paying the price pf
>> breaking compat anyway...
>>
>> Arguably we could also say that given that there's been little evident
>> problems with the borked computation we could also switch to a much
>> faster hash instead of continuing to use crc...
>
> Could a 64 bit variant of some kind be useful as an option - in addition
> to a correct 32 bit?

More bits allows you to detect more errors. That's the only advantage. 
I've never heard that being a problem, so no, I don't think that's a 
good idea.

> As most people have 64 bit processors and storage is less constrained
> now-a-days, as well as we tend to store much larger chunks of data.

That's irrelevant to the CRC in the WAL. Each WAL record is CRC'd 
separately, and they tend to be very small (less than 8k typically) 
regardless of how "large chunks of data" you store in the database.

- Heikki




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pg_receivexlog --status-interval add fsync feedback
Next
From: Simon Riggs
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}