
> 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.

I would hardly call an additional 4 bytes for OID per index entry cheap.

Andreas

Mon, 15 Jan 2001 10:31:23 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: CRCs 
Andreas SB Zeugswetter wrote:
> Tom Lane wrote:
> > Instead of a partial row CRC, we could just as well use some other
> > bit of identifying information, say the row OID. ... 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.
> 
> I would hardly call an additional 4 bytes for OID per index entry
> cheap.

"Cheap enough" is very different from "cheap".  Undetected corruption 
may be arbitrarily expensive when it finally manifests itself.  

That said, maybe storing just the low byte or two of the OID in the 
index would be good enough.  Also, maybe the OID would be there by 
default, but could be ifdef'd out if the size of the indices affects
you noticeably, and you know that your equipment (unlike most) really
does implement strict write ordering.

Nathan Myers
ncm@zembu.com

Mon, 15 Jan 2001 15:45:27 -0800
ncm@zembu.com (Nathan Myers)
Re: CRCs