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

Re: cyclical redundancy checksum algorithm(s)?

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Karen Hill" <karen_hill22(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: cyclical redundancy checksum algorithm(s)?
Date: 2006-09-27 21:10:58
Message-ID: 20060927171058.2e59f70d.wmoran@collaborativefusion.com (view raw or flat)
Thread:
Lists: pgsql-general
In response to Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> "Karen Hill" <karen_hill22(at)yahoo(dot)com> writes:
> > Ralph Kimball states that this is a way to check for changes.  You just
> > have an extra column for the crc checksum.  When you go to update data,
> > generate a crc checksum and compare it to the one in the crc column.
> > If they are same, your data has not changed.
> 
> You sure that's actually what he said?  A change in CRC proves the data
> changed, but lack of a change does not prove it didn't.
> 
> People do sometimes use this logic in connection with much wider
> "summary" functions, such as an MD5 hash.  I wouldn't trust it at all
> with a 32-bit CRC, and not much with a 64-bit CRC.  Too much risk of
> collision.

I remember reading some high-level stuff on rsync and how it uses
multiple checksums in tandem.  Don't know the math, though -- if
both the SHA256 and the MD5 match, what are the chances that it's
changed?

You also hit diminishing returns ... after calculating so many 
checksums, you might be better off just checking the data itself,
unless that data is very large.

-- 
Bill Moran
Collaborative Fusion Inc.

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2006-09-27 21:11:58
Subject: Re: change the order of FROM selection to make query work
Previous:From: Jonathan VanascoDate: 2006-09-27 21:03:15
Subject: memory issues when running with mod_perl

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