On Sun, Feb 05, 2012 at 08:40:09PM +0000, Simon Riggs wrote: > On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Sat, Dec 24, 2011 at 03:56:58PM +0000, Simon Riggs wrote: > >> > Also, as far as I can see this patch usurps the page version field, > >> > which I find unacceptably short-sighted. Do you really think this is > >> > the last page layout change we'll ever make? > >> > >> No, I don't. I hope and expect the next page layout change to > >> reintroduce such a field. > >> > >> But since we're agreed now that upgrading is important, changing page > >> format isn't likely to be happening until we get an online upgrade > >> process. So future changes are much less likely. If they do happen, we > >> have some flag bits spare that can be used to indicate later versions. > >> It's not the prettiest thing in the world, but it's a small ugliness > >> in return for an important feature. If there was a way without that, I > >> would have chosen it. > > > > Have you considered the CRC might match a valuid page version number? > > Is that safe? > > 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. 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. I don't want to get to a point where we need a bit per page number version. -- 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
