Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Block-level CRC checks
Дата
Msg-id 4807.1259692881@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Block-level CRC checks  (Greg Stark <gsstark@mit.edu>)
Re: Block-level CRC checks  (Josh Berkus <josh@agliodbs.com>)
Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, here is another idea, maybe crazy:

> When we read in a page that has an invalid CRC, we check the page to see
> which hint bits are _not_ set, and we try setting them to see if can get
> a matching CRC.  If there no missing hint bits and the CRC doesn't
> match, we know the page is corrupt.  If two hint bits are missing, we
> can try setting one and both of them and see if can get a matching CRC. 
> If we can, the page is OK, if not, it is corrupt.

> Now if 32 hint bits are missing, but could be based on transaction
> status, then we would need 2^32 possible hint bit combinations, so we
> can't do the test and we just assume the page is valid.

A typical page is going to have something like 100 tuples, so
potentially 2^400 combinations to try.  I don't see this being
realistic from that standpoint.  What's much worse is that to even
find the potentially missing hint bits, you need to make very strong
assumptions about the validity of the rest of the page.

The suggestions that were made upthread about moving the hint bits
could resolve the second objection, but once you do that you might
as well just exclude them from the CRC and eliminate the guessing.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [CORE] EOL for 7.4?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Block-level CRC checks