O
> > Always remember that a psotgres data base on the harddisk can be
> > manipulated accidentally / maliciously without postgres even running.
> > These are the cases where you need row level CRCs.
>
> "There is no security without physical security." If somebody can
> change the row contents,
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
"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
> 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 b
"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
> 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. H
> 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 postgre
I believe that there are many good points to have CRC facilities "built
int", and I failed to detect any arguments against it. In my domain (the
medical domain) we simply can't use data without "proof" of integrity
("proof" as in highest possible level of confidence within reasonable
effort)
Th
