On Mon, Feb 06, 2012 at 12:59:59PM -0500, Bruce Momjian wrote: > > > I'm also not very comfortable with the idea of having flags on the page > > > indicating whether it has a checksum or not. It's not hard to imagine a > > > software of firmware bug or hardware failure that would cause pd_flags > > > field > > > to be zeroed out altogether. It would be more robust if the expected > > > bit-pattern was not 0-0, but 1-0 or 0-1, but then you need to deal with > > > that > > > at upgrade somehow. And it still feels a bit whacky anyway. > > > Good idea. Lets use > > > > 0-0-0 to represent upgraded from previous version, needs a bit set > > 0-0-1 to represent new version number of page, no checksum > > 1-1-1 to represent new version number of page, with checksum > > > > So we have 1 bit dedicated to the page version, 2 bits to the checksum > > indicator > > Interesting point that we would not be guarding against a bit flip from > 1 to 0 for the checksum bit; I agree using two bits is the way to go. I > don't see how upgrade figures into this. > > However, I am unclear how Simon's idea above actually works. We need > two bits for redundancy, both 1, to mark a page as having a checksum. I > don't think mixing the idea of a new page version and checksum enabled > really makes sense, especially since we have to plan for future page > version changes. > > I think we dedicate 2 bits to say we have computed a checksum, and 3 > bits to mark up to 8 possible page versions, so the logic is, in > pd_flags, we use bits 0x8 and 0x16 to indicate that a checksum is stored > on the page, and we use 0x32 and later for the page version number. We > can assume all the remaining bits are for the page version number until > we need to define new bits, and we can start storing them at the end > first, and work forward. If all the version bits are zero, it means the > page version number is still stored in pd_pagesize_version.
A simpler solution would be to place two bits for checksum after the existing page bit usage, and place the page version on the last four bits of the 16-bit field --- that still leaves us with 7 unused bits. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
