| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
| Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: Re: TODO list |
| Date: | 2001-04-06 17:25:20 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D338C@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2001-04-06 17:38:05 | Re: RC3 ... |
| Previous Message | The Hermit Hacker | 2001-04-06 17:19:23 | Re: RC3 ... |