Re: Detecting corrupted pages earlier

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Detecting corrupted pages earlier
Дата
Msg-id 7224.1045613313@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Detecting corrupted pages earlier  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Список pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> I'm thinking of modifying ReadBuffer() so that it errors out if the

> What does the *error out* mean ?

Mark the buffer as having an I/O error and then elog(ERROR).

> Is there a way to make our way around the pages ?

If the header is corrupt, I don't think so.  You'd need at the very
least to fix the bad header fields (particularly pd_lower) before you
could safely try to examine tuples.  (In the cases that I've seen,
some or all of the line pointers are clobbered too, making it even less
likely that any useful data can be extracted automatically.)

Basically I'd rather have accesses to the clobbered page fail with
elog(ERROR) than with more drastic errors.  Right now, the least
dangerous result you are likely to get is elog(FATAL) out of the clog
code, and you can easily get a PANIC or backend coredump instead.

> IMHO CRC isn't sufficient because CRC could be calculated
> even for (silently) corrupted pages.

Yeah, it seems a great expense for only marginal additional protection.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Detecting corrupted pages earlier
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Version 7.2.3 Vacuum abnormality