Re: alpha2 initdb PG_CONTROL_VERSION incompatibility?

Josh, Greg,

Thanks for your inputs. Yes, it makes perfect sense that we should have to re-initdb between versions - perfectly reasonable.
But, to be clear, this wasn't what set this snowball in motion...

Your responses piqued my interest... Remember, the core concern was that the 8.5alpha2 pg_ctrl reported that our 8.5alpha1-initdb'd cluster had in fact been initdb'd by 8.4! This got us concerned - as your diagnostic algorithm has suggested - that we had mistakenly built the cluster with the v8.4 initdb binary - and that all our testing thus far might have been against incorrect catalog structure, for example!

So, the scientific process; I repeated the experiment:

Built a new-from-scratch cluster, and initdb'd it with 8.5alpha1
in postgresql.conf, we edited only two parameters:
listen_addresses = '*' and port = 5433 (we use this port for testing)

Then, tried to start the alpha1 cluster with the alpha2 binary:

FATAL: database files are incompatible with server
DETAIL: The database cluster was initialized with PG_CONTROL_VERSION 843, but the server was compiled with PG_CONTROL_VERSION 851.

Again, only concern here is that the error message is misleading, and might set into motion quite a bit of redundant administrative work. Is it just that the PG_CONTROL_VERSIONs don't follow the binary numbering, and this point I simply haven't run into before?

Lou Picciano

PS - (Are you both speaking here - 'we' - as authors of PostgreSQL?)

----- Original Message -----
From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: "Lou Picciano" <loupicciano(at)comcast(dot)net>
Cc: pgsql-testers(at)postgresql(dot)org, "Greg Smith" <gsmith(at)gregsmith(dot)com>
Sent: Tuesday, November 3, 2009 6:26:58 PM GMT -05:00 US/Canada Eastern
Subject: Re: [TESTERS] alpha2 initdb PG_CONTROL_VERSION incompatibility?

Lou,

> The start command we're testing with, for example (the only variable is
> datapath: data-NEW vs. data-OLD):
> # /usr/local/postgres/8.5-alpha2/bin/pg_ctl -D
> /var/postgres/8.5-alpha2/data-NEW -l /var/postgres/8.5-alpha2/TEMPLOG start
> (above works great, with an alpha2-init'd data cluster)

Oh, I don't think there's been any attempt to tell alpha2 that it can
accept an alpha1 InitDB. You have to re-initdb with each alpha. We're
still making catalog changes.

--Josh Berkus

On Wed, 4 Nov 2009, Lou Picciano wrote:

> Is it just that the PG_CONTROL_VERSIONs don't follow the binary
> numbering, and this point I simply haven't run into before?

They match on official releases, but nobody worried about that detail for
the first 8.5 alpha. It's basically impossible for an official release to
make it all the way out the door without *something* causing a "catalog
version bump", the thing that causes that number to be updated so the
first couple of digits look right. There just didn't happen to be any
such changes between the 8.4 release and the first 8.5 alpha.

> > We're still making catalog changes.
> PS -  (Are you both speaking here - 'we' - as authors of PostgreSQL?)

That's specifically "we" as in "everyone who authors a change commited to
PostgreSQL", which essentially includes everyone who might submit a patch.
The committers have very strict rules for making changes to this version
number during the course of official releases because it causes your old
database installation to be incompatible (summary: don't do that; it has
happened extremely rarely to fix serious bugs). This treadmill where you
have to keep running initdb is essentially limited to pre-release testing,
those who build regularly from CVS snapshots have to do this all the time.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD