Re: 16-bit page checksums for 9.2

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: 16-bit page checksums for 9.2
Дата
Msg-id A5220FCC-1321-47CF-8C23-2DD40467B761@nasby.net
обсуждение исходный текст
Ответ на Re: 16-bit page checksums for 9.2  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Jan 3, 2012, at 4:21 PM, Kevin Grittner wrote:
> (2)  I'm not sure about doing this in three parts, to skip the
> checksum itself and the hole in the middle of the page.  Is this
> because the hole might not have predictable data?  Why would that
> matter, as long as it is read back the same?

IMO not checksumming the free space would be a really bad idea. It's entirely possible to have your hardware crapping
onyour free space, and I'd still want to know that that was happening. Now, it would be interesting if the free space
couldbe checksummed separately, since there's no reason to refuse to read the page if only the free space is screwed
up...But given the choice, I'd rather get an error when the free space is "corrupted" and be forced to look into things
ratherthan blissfully ignore corrupted free space only to be hit later with real data loss. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [RFC] grants vs. inherited tables
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Should I implement DROP INDEX CONCURRENTLY?