RE: Re: TODO list
От | Mikheev, Vadim |
---|---|
Тема | RE: Re: TODO list |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D338C@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответ на | TODO list (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Re: TODO 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 по дате отправления: