Hmm, I can get around the btree problem by not summing the "special
space". This loses a bit of reliability because some of the most
critical bits of the page would not be protected by the CRC, but the
bulk of the data would be. And this allows me to get away from page
type specific tricks (like btpo_cycleid which is used as a hint bit).
The reason I noticed this is that I started wondering about only summing
the part of the page that's actually used, i.e. the header, the line
pointers, and the area beyond pd_upper. I then noticed that if I only
include the area between pd_upper and pd_special then I don't need to
care about those bits.
So far, the only other idea I've had is to keep a list of page types
(gin, gist, btree, hash, heap; am I missing something else?) and each
module would provide a routine to do the summing. (Or perhaps better:
the routine they provide says how to sum the special area of the page.
That would allow having a single routine to check the bulk of the page,
and the type-specific routine sums the summable parts of the special
area.)
Thoughts?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
