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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
