Re: What exactly is our CRC algorithm?

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: What exactly is our CRC algorithm?
Date: 2014-10-09 06:47:45
Message-ID: 54362F91.4050904@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Connor Wolf 2014-10-09 07:09:58 Understanding and implementing a GiST Index
Previous Message Heikki Linnakangas 2014-10-09 06:37:39 Re: pg_receivexlog --status-interval add fsync feedback