Re: Did we really want to force an initdb in beta2? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Did we really want to force an initdb in beta2?
Date
Msg-id AANLkTimbTEZZyV1cRMDPwrbbJDKghwHSGREAQiQQBb5B@mail.gmail.com
Whole thread Raw
In response to Re: Did we really want to force an initdb in beta2?  (Dave Page <dpage@pgadmin.org>)
Responses Re: Did we really want to force an initdb in beta2?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jun 4, 2010 at 11:06 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Dave Page wrote:
>>>> Shouldn't we have bumped the catversion? The installers can't tell
>>>> that beta1 clusters won't work with beta2 :-(
>>
>>> That is an interesting point.  Tom bumped the pg_control version, but
>>> not the catalog version.
>>
>> Right, because the catalog contents didn't change.  Seems to me you'd
>> better teach the installers to look at PG_CONTROL_VERSION too.
>
> Hmm, is there anything else that might need to be checked?

XLOG_PAGE_MAGIC, for one.  PG_PAGE_LAYOUT_VERSION doesn't change very
often, but might also fall into the same category.

Tablespace directory paths depend on the value of PG_MAJORVERSION.

It would be nice to have all of these documented somewhere along with
the criteria for bumping each one.  It's relatively easy for a new
committer (ahem) to not realize that there's a version number that
needs to be bumped someplace, and recent experience has shown that
even an experienced committer can goof.  :-)

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Exposing the Xact commit order to the user
Next
From: Tom Lane
Date:
Subject: Re: Did we really want to force an initdb in beta2?