RE: Re: TODO list - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Re: TODO list
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D338C@sectorbase1.sectorbase.com
Whole thread Raw
In response to TODO list  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: TODO list  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: RC3 ...
Next
From: Peter Eisentraut
Date:
Subject: Re: RC3 ...