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