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
|
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: