Re: [ANNC][RFC] crypto hashes for PostgreSQL 7.0, 7.1 - Mailing list pgsql-hackers

From Horst Herb
Subject Re: [ANNC][RFC] crypto hashes for PostgreSQL 7.0, 7.1
Date
Msg-id 002101c03bb9$5fe67060$e7d2fea9@esmith.midgard
Whole thread Raw
In response to [ANNC][RFC] crypto hashes for PostgreSQL 7.0, 7.1  (Marko Kreen <marko@l-t.ee>)
List pgsql-hackers
> Btw, the concept of checksumming rows is kinda new to me.
> I needed this to store passwords on a table, so sorry if I
> cant be more help.  But I am a litte bit curious, why is it
> needed?  Simple checksumming (crc32/md5) does not help malicious
> changing of data, only hardware failures, but today's hardware
> has itself checksumming builtin...  It probably would be a
> more point if you do some pgp/gpg style signing so you would
> get some authenticy too, but this is hard to implement right.

1.) checksumming a row will alert you when glitches have changed data. Happened twice in 3 years to me with my previous
system(with top end hardware!). This is probably due to file system or hardware failures. There is no other way to find
outwhether such a glitch has happened other than regularly checking the checksums. Despite all progress in hardware,
theseerrors still happen and I have these happenings well documented. Most of the people never will notice as they do
notuse such a checking.
 

2.) We had problems before with tunneled IP connections and corrupted data. These errors are very rare, but again, they
canhappen - the more complex your network setup is, the more likely you might get a glitch or two per year. I never fou
dout what to blame: the protocol implementation, the server, the client ...
 
With large packet sizes, the checksumming the network protocols use is not as collision proof as one might wish. The
samecrc works more reliable with small amounts of data than with larger amounts.
 

3.) This checksumming helps to check whether a complex database setup with lots of triggers and interdependencies
reallystores the data the way it is supposed to as you can do the same calculation on the client and compare after
commitment.Helps a lot while testing such a setup
 

Horst



pgsql-hackers by date:

Previous
From: "Vadim Mikheev"
Date:
Subject: Re: foreign key introduces unnecessary locking ?
Next
From: Hiroshi Inoue
Date:
Subject: Re: relation ### modified while in use