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
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 |