On 06.02.2012 05:48, Bruce Momjian wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +0000, Simon Riggs wrote:
In the proposed scheme there are two flag bits set on the page to
indicate whether the field is used as a checksum rather than a version
number. So its possible the checksum could look like a valid page
version number, but we'd still be able to tell the difference.
Thanks. Clearly we don't need 16 bits to represent our page version
number because we rarely change it. The other good thing is I don't
remember anyone wanting additional per-page storage in the past few
years except for a checksum.
There's this idea that I'd like to see implemented:
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01176.php
In any case, I think it's a very bad idea to remove the page version
field. How are we supposed to ever be able to change the page format
again if we don't even have a version number on the page? I strongly
oppose removing it.
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.
I wonder if we should just dedicate 3 page header bits, call that the
page version number, and set this new version number to 1, and assume
all previous versions were zero, and have them look in the old page
version location if the new version number is zero. I am basically
thinking of how we can plan ahead to move the version number to a new
location and have a defined way of finding the page version number using
old and new schemes.
Three bits seems short-sighted, but yeah, something like 6-8 bits should
be enough. On the whole, though. I think we should bite the bullet and
invent a way to extend the page header at upgrade.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
