Re: CRCs

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: CRCs
Date: 2001-01-13 23:33:59
Message-ID: 20010113153359.A8821@store.zembu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 13, 2001 at 12:49:34PM -0500, Tom Lane wrote:
> ncm(at)zembu(dot)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(at)zembu(dot)com

In response to

  • Re: CRCs at 2001-01-13 17:49:34 from Tom Lane

Responses

  • Re: CRCs at 2001-01-14 04:20:30 from Tom Lane

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2001-01-14 01:21:57 Transactions vs speed.
Previous Message selkovjr 2001-01-13 23:31:25 Re: Re: AW: Re: GiST for 7.1 !!