On Sat, Jan 13, 2001 at 12:49:34PM -0500, Tom Lane wrote:
> ncm@zembu.com (Nathan Myers) writes:
> > ... for systems that cannot provide strict write ordering (e.g.,
> > most PCs) it would be helpful to be able to detect that the database
> > has become corrupted. In Vadim's example above, if the index were to
> > contain not only the heap blocks' numbers, but also their CRCs, then
> > the corruption could be detected when the index is used. ...
>
> A row-level CRC might be useful for this, but it would have to be on
> the data only (not the tuple commit-status bits). It'd be totally
> impractical with a block CRC, I think. ...
I almost wrote about an indirect scheme to share the expected block CRC
value among all the index entries that need it, but thought it would
distract from the correct approach:
> Instead of a partial row CRC, we could just as well use some other bit
> of identifying information, say the row OID. ...
Good. But, wouldn't the TID be more specific? True, it would be pretty
unlikely for a block to have an old tuple with the right OID in the same
place. Belt-and-braces says check both :-). Either way, the check seems
independent of block CRCs. Would this check be simple enough to be safe
for 7.1?
Nathan Myers
ncm@zembu.com
