> 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.
row level is neccessary to be able tocheck integrity at application level.
> I suspect TOAST breaks your notion of computing a CRC at trigger time
> anyway --- some of the fields may be toasted already, some not.
The workaround is a loggingtable where you store the crcs as well. Lateron,
an "integrity daemon" can compare whether match or 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
Oh, sure, that is the way we do it now. And no, nothing to do with paranoia.
Burnt previously badly by assumption that a decent SQL server is a
"guarantee" for data integrity. Shit simply happens.
> end-to-end coverage. Surely you don't trust your TCP connection to the
> server, either?
TCP _IS_ heavily checksummed. But yes, we _do_ calculate checksums at the
client, recalculate at the server, and compare after the transaction is
completed. As we have only few writes between heavy read access, the
performance penalty doing this (for our purposes) is minimal.
Horst