From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: What exactly is our CRC algorithm? |
Date: | 2014-12-26 18:48:40 |
Message-ID: | 20141226184840.GE3763@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 26, 2014 at 11:52:41PM +0530, Abhijit Menon-Sen wrote:
> At 2014-12-26 13:11:43 -0500, bruce(at)momjian(dot)us wrote:
> >
> > Is this something that could potentially change the data stored on
> > disk? Does pg_upgrade need to check for changes in this area? Is the
> > detection exposed by pg_controldata? Could this affect running the
> > data directory on a different CPU?
>
> No to all.
>
> Subsequent to Heikki's change (already in master) to use the CRC-32C
> algorithm (instead of the earlier mistakenly-reflected-but-not-quite
> one), both the slice-by-8 software implementation posted earlier and
> the SSE4.2 CRC32* instructions will compute exactly the same value.
>
> (Yes, I have verified this in both cases.)
Uh, we didn't fully change all code to use the new algorithm because
there were cases that the CRC was already stored on disk, e.g hstore,
ltree. I assume you are only linking into Heikki's new code and will
not change the places that use the old CRC method on disk --- just
checking.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2014-12-26 18:50:23 | Re: What exactly is our CRC algorithm? |
Previous Message | Nikita Volkov | 2014-12-26 18:45:32 | Re: BUG #12330: ACID is broken for unique constraints |