From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Horst Herb" <hherb(at)malleenet(dot)net(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFC: CRC datatype |
Date: | 2000-12-08 16:49:00 |
Message-ID: | 890.976294140@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Horst Herb" <hherb(at)malleenet(dot)net(dot)au> writes:
> AFAIK the thread for "built in" crcs referred only to CRCs in the
> transaction log. This here is a different thing. CRCs in the transaction log
> are crucial to proof integrity of the log, CRCs as datatype are neccessary
> to proof integrity of database entries at row level.
I think a row-level CRC is rather pointless. Perhaps it'd be a good
idea to have a disk-page-level CRC, though. That would check the rows
on the page *and* allow catching errors in the page and tuple overhead
structures, which row-level CRCs would not cover.
I suspect TOAST breaks your notion of computing a CRC at trigger time
anyway --- some of the fields may be toasted already, some not.
If you're sufficiently paranoid that you insist you need a row-level
CRC, it seems to me that you'd want to generate it and later check it
in your application, not in the database. That's the only way you get
end-to-end coverage. Surely you don't trust your TCP connection to the
server, either?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrizio Manfredi | 2000-12-08 16:49:03 | Re: Threads |
Previous Message | The Hermit Hacker | 2000-12-08 16:19:56 | Re: Indexing for geographic objects? |