On Tue, Jan 3, 2012 at 11:00 PM, Jim Nasby <j...@nasby.net> wrote: > 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 on your free space, and I'd still > want to know that that was happening. Now, it would be interesting if the > free space could be 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 rather than blissfully ignore corrupted free space > only to be hit later with real data loss.
I see that argument. We don't have space for 2 checksums. We can either (1) report all errors on a page, including errors that don't change PostgreSQL data. This involves checksumming long strings of zeroes, which the checksum algorithm can't tell apart from long strings of ones. (2) report only errors that changed PostgreSQL data. We already do (1) for WAL CRCs so doing the same thing for page checksums makes sense and is much faster. If enough people think we should do (2) then its a simple change to the patch. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
