> To be perfectly clear: I have actually seen bug reports trace to
> problems that I think a block-level CRC might have detected (not
> corrected, of course, but at least the user might have realized he had
> flaky hardware a little sooner).  So I do not say that the upside to
> a block CRC is nil.  But I am unconvinced that it exceeds the
> downside, in development effort, runtime, false failure reports
> (is that CRC error really due to hardware trouble, or a software bug
> that failed to update the CRC? and how do you get around the CRC error
> to get at your data??) etc etc.

Something to remember: currently we update t_infomask (set
HEAP_XMAX_COMMITTED etc) while holding share lock on buffer -
we have to change this before block CRC implementation.

Vadim

Fri, 6 Apr 2001 10:25:20 -0700 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Re: TODO list 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Something to remember: currently we update t_infomask (set
> HEAP_XMAX_COMMITTED etc) while holding share lock on buffer -
> we have to change this before block CRC implementation.

Yeah, we'd lose some concurrency there.

			regards, tom lane

Fri, 06 Apr 2001 14:46:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: TODO list 