Skip site navigation (1) Skip section navigation (2)

Re: Uh, this is *not* a 64-bit CRC ...

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Uh, this is *not* a 64-bit CRC ...
Date: 2001-02-28 22:42:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 28, 2001 at 04:53:09PM -0500, Tom Lane wrote:
> I just took a close look at the COMP_CRC64 macro in xlog.c.
> This isn't a 64-bit CRC.  It's two independent 32-bit CRCs, one done
> on just the odd-numbered bytes and one on just the even-numbered bytes
> of the datastream.  That's hardly any stronger than a single 32-bit CRC;
> it's certainly not what I thought we had agreed to implement.
> We can't change this algorithm without forcing an initdb, which would be
> a rather unpleasant thing to do at this late stage of the release cycle.
> But I'm not happy with it.  Comments?

This might be a good time to update:

  The CRC-64 code used in the SWISS-PROT genetic database is (now) at:

  From the README:

  The code in this package has been derived from the BTLib package
  obtained from Christian Iseli <chris(at)ludwig-alpha(dot)unil(dot)ch>.
  From his mail:

  The reference is: W. H. Press, S. A. Teukolsky, W. T. Vetterling, and
  B. P.  Flannery, "Numerical recipes in C", 2nd ed., Cambridge University
  Press.  Pages 896ff.

  The generator polynomial is x64 + x4 + x3 + x1 + 1.

I would suggest that if you don't change the algorithm, at least change
the name in the sources.  Were you to #ifdef in a real crc-64, and make 
a compile-time option to select the old one, you could allow users who 
wish to avoid the initdb a way to continue with the existing pair of 

Nathan Myers

In response to


pgsql-hackers by date

Next:From: Rainer MagerDate: 2001-02-28 23:01:32
Subject: RE: COPY doesn't works when containing ' ' or ' ' characters on db
Previous:From: Thomas LockhartDate: 2001-02-28 22:07:31
Subject: Re: Release in 2 weeks ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group