Re: Checksums, state of play - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Checksums, state of play
Date
Msg-id CA+TgmoYBCqdCLQx-y0-beSHaYYmRErWwBv_m6nSoRJmX8LdPTA@mail.gmail.com
Whole thread Raw
In response to Re: Checksums, state of play  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Checksums, state of play  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Mar 6, 2012 at 12:00 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Mar 6, 2012 at 4:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> As to whether we should increment pd_pagesize_version, I'm not sure
>> quite what you were saying about that (I think you may have an extra
>> or missing word there), but I don't think it's necessary here.
>
> I said this...
>
> On Tue, Mar 6, 2012 at 3:40 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Do you know of any PostgreSQL variant that can set this byte range to
>> different values?
>
> Not sure what the missing word is there, so I'll ask again.
>
> Has EDB or anybody else you know of has used the pd_pagesize_version
> field for something else, so you'd rather I didn't touch that?

To my knowledge, EDB has not ever stamped pages with a different
pd_pagesize_version, or reused that field for any other purpose, but
I'm not sure about Greenplum or others.  I have seen at least one
pg_filedump output where every page was stamped with the same very odd
value there; I don't remember what the value was, and I don't know
where the output I was sent came from, but it was enough to make me
wonder if somebody's done that.

That's not why I want to leave that field alone, though: I want to
leave that field alone for backward and forward compatibility, so that
any version of community PostgreSQL ever released - and any page
inspection tools, current or future - can look at the low-order byte
of that field and know what page version they've got.  If we didn't
have some other bytes in the page header that seem relatively useless
(like pd_tli and the high bits of pd_pagesize_version), I'd be arguing
for extending the page header rather than clobbering the version
number.  It just seems to me that the page version number is
absolutely the most basic piece of information on the page, which you
must have before you can interpret the rest of the page contents.  For
it to have any value in identifying past page format changes, future
page format changes, or format changes by forks of our main code base,
it's got to be present in every release and have the same meaning in
each one.  If we do a release where "2" can mean "the checksum is 2"
rather than "the page was written by PostgreSQL 8.0" then we've
forever lost the ability to decide, without the use of heuristics,
what kind of page we've got.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Checksums, state of play
Next
From: Heikki Linnakangas
Date:
Subject: Re: Checksums, state of play