Re: CRCs

ncm@zembu.com (Nathan Myers) writes:
> To achieve disk write-order independence is probably not a worthwhile 
> goal, but 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.  When the 
> block is read in, its CRC is checked, and when it is referenced via 
> the index, the two CRC values are simply compared and the corruption
> is revealed. 

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.  To do it with a block CRC, every
time you changed *anything* in a heap page, you'd have to find all the
index items for each row on the page and update their copies of the
heap block's CRC.  That could easily turn one disk-write into hundreds,
not to mention the index search costs.  Similarly, a check value that is
affected by tuple status updates would enormously increase the cost of
marking tuples committed or dead.

Instead of a partial row CRC, we could just as well use some other bit
of identifying information, say the row OID.  Given a block CRC on the
heap page, we'll be pretty confident already that the heap page is OK,
we just need to guard against the possibility that it's older than the
index item.  Checking that there is a valid tuple at the slot indicated
by the index item, and that it has the right OID, should be a good
enough (and cheap enough) test.
        regards, tom lane