On Thu, Mar 1, 2012 at 9:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> One thing I'm not too sure about is how to extend the page format to >> handle optional features. For example, suppose we want to add 2 bytes >> to the page header for a checksum (or 4 bytes, or any other number). >> Ideally, I'd like to not use up those 2 bytes on pages that aren't >> checksummed. What do we do about that? > > I'm having a hard time getting excited about adding that requirement on > top of all the others that we have for this feature. In particular, if > we insist on that, there is exactly zero chance of turning checksums on > on-the-fly, because you won't be able to do it if the page is full. > > The scheme that seems to me to make the most sense for checksums, > if we grant Simon's postulate that a 2-byte checksum is enough, is > (1) repurpose the top N bits of pd_flags as a page version number, > for some N; > (2) repurpose pd_pagesize_version as the checksum, with the > understanding that you can't have a checksum in version-0 pages. > > (Simon's current patch seems to be an overengineered version of that. > Possibly we should also ask ourselves how much we really need pd_tli > and whether that couldn't be commandeered as the checksum field.) > > I see the page versioning stuff as mainly being of interest for changes > that are more invasive than this, for instance tuple-header or data > changes.
Well, OK, so... it wouldn't bother me a bit to steal pd_tli for this, although Simon previously objected to steeling even half of it, when I suggested that upthread. But I don't see the point of your first proposal: keeping the page version right where it is is a good idea, and we should do it. We could steel some *high* order bits from that field without breaking anything, but moving it around seems like it will complicate life to no good purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers