Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 23305.1330654291@sss.pgh.pa.us
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: 16-bit page checksums for 9.2  (Robert Haas <robertmhaas@gmail.com>)
Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade --logfile option documentation
Next
From: Peter Geoghegan
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)