Thread: alpha2 initdb PG_CONTROL_VERSION incompatibility?
Fellow testers:
We've just implemented a fresh build of 8.5alpha2 Solaris 10 SPARC...
Interestingly, the server reports:
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
Strangely, these datafiles were init'd by 8.5 alpha1, and that server has been running without objection.
However, we see the same log messages with 8.5 alpha2 against a freshly init'd cluster, built with alpha2's initdb command, or when using data init'd by alpha1.
Weird!
Lou
We've just implemented a fresh build of 8.5alpha2 Solaris 10 SPARC...
Interestingly, the server reports:
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
Strangely, these datafiles were init'd by 8.5 alpha1, and that server has been running without objection.
However, we see the same log messages with 8.5 alpha2 against a freshly init'd cluster, built with alpha2's initdb command, or when using data init'd by alpha1.
Weird!
Lou
On Tue, 3 Nov 2009, Lou Picciano wrote: > 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 > > Strangely, these datafiles were init'd by 8.5 alpha1, and that server has been running without objection. > > However, we see the same log messages with 8.5 alpha2 against a freshly init'd cluster, built with alpha2's > initdb command, or when using data init'd by alpha1. Normally when this happens it's either because you're accidentially using the old initdb due to a PATH quirk you didn't anticipate, or PGDATA is pointing to the wrong place; maybe you set it explictly in initdb using "-d" but it's pointing at the wrong place? The troubleshooting path to figure out what causes this is to see if you're getting something that still points to the old version from the following: echo $PGDATA which initdb initdb --version which pg_ctl pg_ctl --version The other thing that can be helpful to confirm what is happening is to look at the output from pg_config to see where it put everything at. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg,
Thanks for your feedback - those concerns are the first ones we double-tested. In fact, we've been using explicit, full-path commands specifically to preclude the possibility of a 'wrong-path' error. We do have a few PostgreSQL clusters running here, on different ports, for various testing, so we're pretty attentive to all this.
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)
Same command, using the alpha1 cluster - the 'OLD' cluster:
# /usr/local/postgres/8.5-alpha2/bin/pg_ctl -D /var/postgres/8.5-alpha2/data-OLD -l /var/postgres/8.5-alpha2/TEMPLOG start
(reports: The database cluster was initialized with PG_CONTROL_VERSION 843, but the server was compiled with PG_CONTROL_VERSION 851)
For the sake of argument, let's test the possibility I had init'd the cluster with an 8.4 initdb:
But this command - the alpha1 binary loading the 'OLD' cluster:
# /usr/local/postgres/8.5-alpha1/bin/pg_ctl -D /var/postgres/8.5-alpha2/data-OLD -l /var/postgres/8.5-alpha2/LOULOG start
Works just fine!
$PGDATA is empty
# /usr/local/postgres/8.5-alpha2/bin/pg_ctl --version
pg_ctl (PostgreSQL) 8.5alpha2
Weird, huh?
Lou Picciano
----- Original Message -----
From: "Greg Smith" <gsmith@gregsmith.com>
To: "Lou Picciano" <loupicciano@comcast.net>
Cc: "pgsql-testers" <pgsql-testers@postgresql.org>
Sent: Tuesday, November 3, 2009 3:17:42 PM GMT -05:00 US/Canada Eastern
Subject: Re: [TESTERS] alpha2 initdb PG_CONTROL_VERSION incompatibility?
On Tue, 3 Nov 2009, Lou Picciano wrote:
> 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
>
> Strangely, these datafiles were init'd by 8.5 alpha1, and that server has been running without objection.
>
> However, we see the same log messages with 8.5 alpha2 against a freshly init'd cluster, built with alpha2's
> initdb command, or when using data init'd by alpha1.
Normally when this happens it's either because you're accidentially using
the old initdb due to a PATH quirk you didn't anticipate, or PGDATA is
pointing to the wrong place; maybe you set it explictly in initdb using
"-d" but it's pointing at the wrong place?
The troubleshooting path to figure out what causes this is to see if
you're getting something that still points to the old version from the
following:
echo $PGDATA
which initdb
initdb --version
which pg_ctl
pg_ctl --version
The other thing that can be helpful to confirm what is happening is to
look at the output from pg_config to see where it put everything at.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Thanks for your feedback - those concerns are the first ones we double-tested. In fact, we've been using explicit, full-path commands specifically to preclude the possibility of a 'wrong-path' error. We do have a few PostgreSQL clusters running here, on different ports, for various testing, so we're pretty attentive to all this.
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)
Same command, using the alpha1 cluster - the 'OLD' cluster:
# /usr/local/postgres/8.5-alpha2/bin/pg_ctl -D /var/postgres/8.5-alpha2/data-OLD -l /var/postgres/8.5-alpha2/TEMPLOG start
(reports: The database cluster was initialized with PG_CONTROL_VERSION 843, but the server was compiled with PG_CONTROL_VERSION 851)
For the sake of argument, let's test the possibility I had init'd the cluster with an 8.4 initdb:
But this command - the alpha1 binary loading the 'OLD' cluster:
# /usr/local/postgres/8.5-alpha1/bin/pg_ctl -D /var/postgres/8.5-alpha2/data-OLD -l /var/postgres/8.5-alpha2/LOULOG start
Works just fine!
$PGDATA is empty
# /usr/local/postgres/8.5-alpha2/bin/pg_ctl --version
pg_ctl (PostgreSQL) 8.5alpha2
Weird, huh?
Lou Picciano
----- Original Message -----
From: "Greg Smith" <gsmith@gregsmith.com>
To: "Lou Picciano" <loupicciano@comcast.net>
Cc: "pgsql-testers" <pgsql-testers@postgresql.org>
Sent: Tuesday, November 3, 2009 3:17:42 PM GMT -05:00 US/Canada Eastern
Subject: Re: [TESTERS] alpha2 initdb PG_CONTROL_VERSION incompatibility?
On Tue, 3 Nov 2009, Lou Picciano wrote:
> 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
>
> Strangely, these datafiles were init'd by 8.5 alpha1, and that server has been running without objection.
>
> However, we see the same log messages with 8.5 alpha2 against a freshly init'd cluster, built with alpha2's
> initdb command, or when using data init'd by alpha1.
Normally when this happens it's either because you're accidentially using
the old initdb due to a PATH quirk you didn't anticipate, or PGDATA is
pointing to the wrong place; maybe you set it explictly in initdb using
"-d" but it's pointing at the wrong place?
The troubleshooting path to figure out what causes this is to see if
you're getting something that still points to the old version from the
following:
echo $PGDATA
which initdb
initdb --version
which pg_ctl
pg_ctl --version
The other thing that can be helpful to confirm what is happening is to
look at the output from pg_config to see where it put everything at.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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 Tue, 3 Nov 2009, Lou Picciano wrote: > 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) OK, the original message you sent suggested this didn't work either which was the confusing part. The fact that you have to do a fresh initdb to go from anything earlier to alpha2 is expected. The fact that you could go from 8.4 to 8.5-alpha just reflects that nobody made any internal changes to the database layout between those versions. That it worked was a lucky oddity, what you're seeing now is the more common situation. In general, you have to do a fresh initdb for each testing release to make a database cluster that the new code will talk to. That this changes each sub-release is one reason these are strictly useful as test releases. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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@agliodbs.com>
To: "Lou Picciano" <loupicciano@comcast.net>
Cc: pgsql-testers@postgresql.org, "Greg Smith" <gsmith@gregsmith.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
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@agliodbs.com>
To: "Lou Picciano" <loupicciano@comcast.net>
Cc: pgsql-testers@postgresql.org, "Greg Smith" <gsmith@gregsmith.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@gregsmith.com http://www.gregsmith.com Baltimore, MD