Re: RFC: CRC datatype

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

In response to

Responses

Browse pgsql-hackers by date

  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?