Re: Page Checksums

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Page Checksums
Дата
Msg-id 4EF1A5310200002500043F37@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Page Checksums  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Page Checksums  (Andres Freund <andres@anarazel.de>)
Re: Page Checksums  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Greg Smith <greg@2ndQuadrant.com> wrote:
>>  Some people think I border on the paranoid on this issue.
> 
> Those people are also out to get you, just like the hardware.
Hah!  I *knew* it!
>> Are you arguing that autovacuum should be disabled after crash
>> recovery?  I guess if you are arguing that a database VACUUM
>> might destroy recoverable data when hardware starts to fail, I
>> can't argue.
> 
> A CRC failure suggests to me a significantly higher possibility
> of hardware likely to lead to more corruption than a normal crash
> does though.
Yeah, the discussion has me coming around to the point of view
advocated by Andres: that it should be treated the same as corrupt
pages detected through other means.  But that can only be done if
you eliminate false positives from hint-bit-only updates.  Without
some way to handle that, I guess that means the idea is dead.
Also, I'm not sure that our shop would want to dedicate any space
per page for this, since we're comparing between databases to ensure
that values actually match, row by row, during idle time.  A CRC or
checksum is a lot weaker than that.  I can see where it would be
very valuable where more rigorous methods aren't in use; but it
would really be just extra overhead with little or no benefit for
most of our database clusters.
-Kevin


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Page Checksums
Следующее
От: Robert Haas
Дата:
Сообщение: Re: CLOG contention