Re: 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>From pgsql-testers-owner(at)postgresql(dot)org Tue Nov 3 19:23:44 2009
Received: from localhost (unknown [200.46.208.211])
by mail.postgresql.org (Postfix) with ESMTP id 429B16342A8
for <pgsql-testers-postgresql(dot)org(at)mail(dot)postgresql(dot)org>; Tue, 3 Nov 2009 19:23:44 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
with ESMTP id 21327-04
for <pgsql-testers-postgresql(dot)org(at)mail(dot)postgresql(dot)org>;
Tue, 3 Nov 2009 23:23:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56])
by mail.postgresql.org (Postfix) with ESMTP id 4C7E0633931
for <pgsql-testers(at)postgresql(dot)org>; Tue, 3 Nov 2009 19:23:33 -0400 (AST)
Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76])
by QMTA06.westchester.pa.mail.comcast.net with comcast
id 0csW1d0031ei1Bg56nNCY1; Tue, 03 Nov 2009 23:22:12 +0000
Received: from sz0093.wc.mail.comcast.net ([76.96.58.151])
by OMTA24.westchester.pa.mail.comcast.net with comcast
id 0nX31d0043FmDic3knX39u; Tue, 03 Nov 2009 23:31:03 +0000
Date: Tue, 3 Nov 2009 23:23:32 +0000 (UTC)
From: Lou Picciano <loupicciano(at)comcast(dot)net>
To: pgsql-testers <pgsql-testers(at)postgresql(dot)org>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>
Message-ID: <329060923(dot)6534111257290612647(dot)JavaMail(dot)root(at)sz0093a(dot)westchester(dot)pa(dot)mail(dot)comcast(dot)net>
In-Reply-To: <1719086111(dot)6533311257290506603(dot)JavaMail(dot)root(at)sz0093a(dot)westchester(dot)pa(dot)mail(dot)comcast(dot)net>
Subject: Re: alpha2 initdb PG_CONTROL_VERSION incompatibility?
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_329078_1167426502.1257290612645"
X-Originating-IP: [68.37.107.119]
X-Mailer: Zimbra 5.0.18_GA_3076.RHEL5_64 (ZimbraWebClient - FF3.0 (Mac)/5.0.18_GA_3076.RHEL5_64)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5
tests=BAYES_00=-2.599, HTML_MESSAGE=0.001
X-Spam-Level:
X-Archive-Number: 200911/3
X-Sequence-Number: 8

------=_Part_329078_1167426502.1257290612645
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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(at)gregsmith(dot)com>
To: "Lou Picciano" <loupicciano(at)comcast(dot)net>
Cc: "pgsql-testers" <pgsql-testers(at)postgresql(dot)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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
------=_Part_329078_1167426502.1257290612645
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Verdana; font-size: 12pt; color: #000000'>Greg,<b=
r><br>Thanks for your feedback - those concerns are the first ones we doubl=
e-tested.&nbsp; In fact, we've been using explicit, full-path commands spec=
ifically to preclude the possibility of a 'wrong-path' error.&nbsp; We do h=
ave a few PostgreSQL clusters running here, on different ports, for various=
testing, so we're pretty attentive to all this.<br><br>The start command w=
e're testing with, for example (the only variable is datapath: data-NEW vs.=
data-OLD):<br># /usr/local/postgres/8.5-alpha2/bin/pg_ctl -D /var/postgres=
/8.5-alpha2/<span style=3D"font-weight: bold;">data-NEW</span> -l /var/post=
gres/8.5-alpha2/TEMPLOG start<br>(above works great, with an alpha2-init'd =
data cluster)<br><br>Same command, using the alpha1 cluster - the 'OLD' clu=
ster:<br># /usr/local/postgres/8.5-alpha2/bin/pg_ctl -D /var/postgres/8.5-a=
lpha2/<span style=3D"font-weight: bold;">data-OLD</span> -l /var/postgres/8=
.5-alpha2/TEMPLOG start<br>(reports: The database cluster was initialized w=
ith PG_CONTROL_VERSION 843, but the server was compiled with PG_CONTROL_VER=
SION 851)<br><br>For the sake of argument, let's test the possibility I had=
init'd the cluster with an 8.4 initdb:<br>But this command - the alpha1 bi=
nary loading the 'OLD' cluster:<br># /usr/local/postgres/8.5-alpha1/bin/pg_=
ctl -D /var/postgres/8.5-alpha2/<span style=3D"font-weight: bold;">data-OLD=
</span> -l /var/postgres/8.5-alpha2/LOULOG start<br>Works just fine!<br><br=
>$PGDATA is empty<br># /usr/local/postgres/8.5-alpha2/bin/pg_ctl --version&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; <br>pg_ctl (PostgreSQL) 8.5alpha2<br><br>Weird, huh?<br><br>Lou Picciano=
<br><br>----- Original Message -----<br>From: "Greg Smith" &lt;gsmith(at)gregs=
mith.com&gt;<br>To: "Lou Picciano" &lt;loupicciano(at)comcast(dot)net&gt;<br>Cc: "=
pgsql-testers" &lt;pgsql-testers(at)postgresql(dot)org&gt;<br>Sent: Tuesday, Novem=
ber 3, 2009 3:17:42 PM GMT -05:00 US/Canada Eastern<br>Subject: Re: [TESTER=
S] alpha2 initdb PG_CONTROL_VERSION incompatibility?<br><br>On Tue, 3 Nov 2=
009, Lou Picciano wrote:<br><br>&gt; FATAL:&nbsp; database files are incomp=
atible with server<br>&gt; DETAIL:&nbsp; The database cluster was initializ=
ed with PG_CONTROL_VERSION 843, but the server was compiled with<br>&gt; PG=
_CONTROL_VERSION 851<br>&gt; <br>&gt; Strangely, these datafiles were init'=
d by 8.5 alpha1, and that server has been running without objection.<br>&gt=
; <br>&gt; However, we see the same log messages with 8.5 alpha2 against a =
freshly init'd cluster, built with alpha2's<br>&gt; initdb command, or when=
using data init'd by alpha1.<br><br>Normally when this happens it's either=
because you're accidentially using <br>the old initdb due to a PATH quirk =
you didn't anticipate, or PGDATA is <br>pointing to the wrong place; maybe =
you set it explictly in initdb using <br>"-d" but it's pointing at the wron=
g place?<br><br>The troubleshooting path to figure out what causes this is =
to see if <br>you're getting something that still points to the old version=
from the <br>following:<br><br>echo $PGDATA<br>which initdb<br>initdb --ve=
rsion<br>which pg_ctl<br>pg_ctl --version<br><br>The other thing that can b=
e helpful to confirm what is happening is to <br>look at the output from pg=
_config to see where it put everything at.<br><br>--<br>* Greg Smith gsmith=
@gregsmith.com http://www.gregsmith.com Baltimore, MD</div></body></html>
------=_Part_329078_1167426502.1257290612645--