On Sat, Dec 09, 2000 at 12:03:52AM +1100, Horst Herb wrote:
AFAIK the thread for "built in" crcs referred only to CRCs in
the transaction log.
We have been discussing checksums for both the table blocks and for
the transaction log.
Always remember that a psotgres data base on the harddisk
Therefore, I propose defining new data types like "CRC32", "CRC64",
"RIPEMD", whatever (rather than pluggable arbitrary CRCs).
I suspect that you are really looking at the problem from the wrong end.
CRC checking should not need to be done by the database user, with a fancy
type. The postgres
I suspect that you are really looking at the problem from the wrong end.
CRC checking should not need to be done by the database user, with a fancy
type. The postgres server itself should guarantee data integrity - you
shouldn't have to worry about it in userland.
I agree in principle.
"Horst Herb" [EMAIL PROTECTED] 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
"Horst Herb" [EMAIL PROTECTED] writes:
Surely you don't trust your TCP connection to the
server, either?
TCP _IS_ heavily checksummed.
Yes, and so are the disk drives that you are asserting you don't trust.
My point is that in both cases, there are lots and lots of failure
mechanisms that
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
