Thread: Problem with initdb and two versions on one server?

Problem with initdb and two versions on one server?

From
Chris McCormick
Date:
Hello all,
    Because of issues with dump/restore, I am instead setting up a
second cluster under a newer version so I can slowly migrate data (I
have 7.4.30, and am adding 8.3.18 on the same box). The problem is
that when I try to start the new postmaster it complains:

"FATAL:  database files are incompatible with server"
"DETAIL: The data directory was initialised by PostgreSQL version 7.4,
which is not compatible with this version 8.3.18."

I compiled 8.3.18 from source, with the following flags in the configure:
1. --prefix=/backup/pgsql8
2. I did NOT use --disable-rpath (i.e., I wanted shared library paths
baked into the executable so it would look first into
/backup/pgsql8/lib first, assuming that the library differences would
be too great between 7.4 and 8.3)
3. --with-pgport=3005 (the existing one is on the standard port)

I configured, compiled, and installed, and saw the various subfolders
appear under /backup/pgsql8 as expected.

I created the data directory and chown'd it to my superuser.

I ran initdb like so:
/backup/pgsql8/bin/initdb –E UTF8 --locale=en_US -D /backup/pgsql8/data

I assumed by using the full path to the new initdb that the data
directory would be initialised in 8.3.18 style. It ran without errors.

When I run pg_ctl, I use the full path:
/backup/pgsql8/bin/pg_ctl -D /backup/pgsql8/data -o “-p 3005” start

But I still get the error.

I am confused. I feel that I have pointed to 8.3 everywhere, yet
somehow the existing 7.4 is involved. I am not sure if the message is
saying:
1. "Your postmaster is 8.3, but you're pointed at the old data
directory" (despite my -D flag)
or
2. "Your data directory is 8.3, but your postmaster is the old 7.4"
(despite my fully-qualified call to pg_ctl)

Thoughts?

Thanks for helping a newbie,
Chris

PS: Yeah, I know /backup ain't the place to put my database. But the
partitions weren't set up right at the beginning, so this is my hack
for now since I ran out of space.

Re: Problem with initdb and two versions on one server?

From
Tom Lane
Date:
Chris McCormick <mccormick1@gmail.com> writes:
> � � Because of issues with dump/restore, I am instead setting up a
> second cluster under a newer version so I can slowly migrate data (I
> have 7.4.30, and am adding 8.3.18 on the same box). The problem is
> that when I try to start the new postmaster it complains:

> "FATAL: �database files are incompatible with server"
> "DETAIL: The data directory was initialised by PostgreSQL version 7.4,
> which is not compatible with this version 8.3.18."

You are starting the 8.3 postmaster, but giving it a -D setting that
points at the 7.4 data directory.  The commands you're showing look
reasonable offhand, but clearly there's something wrong in detail.

One thought that occurs to me is that you might have a PGDATA
environment variable that points at the old data directory ... the
explicit -D switches *should* override that, but maybe are failing to?

Also, the documented syntax for pg_ctl is pg_ctl start [switches],
not what you wrote.  You did not say what the platform is, but some
versions of getopt() try (with varying degrees of success) to rearrange
such commands to meet expectations.  Maybe the -D switch is getting
dropped on the floor somewhere in there.

Another thing worth doing is to examine the PG_VERSION file in each
data directory, just to make sure it contains what you think.

            regards, tom lane

Re: Problem with initdb and two versions on one server?

From
Rainer Pruy
Date:
Hello Chris,

can not provide much help.

But definitely the message sounds like case (1) (8.3 server accessing
7.4 files)

I did encounter such with two occasions:

a) used an old initdb version
b) using an rc script that had hard coded path to the (old) data directory

both cases seem not to apply in your case.

BTW: you may check  PG:VERSION file(s) in data directories to
verify what version those directory are claiming to be.

Rainer

On 28.02.2012 14:46, Chris McCormick wrote:
> Hello all,
>     Because of issues with dump/restore, I am instead setting up a
> second cluster under a newer version so I can slowly migrate data (I
> have 7.4.30, and am adding 8.3.18 on the same box). The problem is
> that when I try to start the new postmaster it complains:
>
> "FATAL:  database files are incompatible with server"
> "DETAIL: The data directory was initialised by PostgreSQL version 7.4,
> which is not compatible with this version 8.3.18."
>
> I compiled 8.3.18 from source, with the following flags in the configure:
> 1. --prefix=/backup/pgsql8
> 2. I did NOT use --disable-rpath (i.e., I wanted shared library paths
> baked into the executable so it would look first into
> /backup/pgsql8/lib first, assuming that the library differences would
> be too great between 7.4 and 8.3)
> 3. --with-pgport=3005 (the existing one is on the standard port)
>
> I configured, compiled, and installed, and saw the various subfolders
> appear under /backup/pgsql8 as expected.
>
> I created the data directory and chown'd it to my superuser.
>
> I ran initdb like so:
> /backup/pgsql8/bin/initdb –E UTF8 --locale=en_US -D /backup/pgsql8/data
>
> I assumed by using the full path to the new initdb that the data
> directory would be initialised in 8.3.18 style. It ran without errors.
>
> When I run pg_ctl, I use the full path:
> /backup/pgsql8/bin/pg_ctl -D /backup/pgsql8/data -o “-p 3005” start
>
> But I still get the error.
>
> I am confused. I feel that I have pointed to 8.3 everywhere, yet
> somehow the existing 7.4 is involved. I am not sure if the message is
> saying:
> 1. "Your postmaster is 8.3, but you're pointed at the old data
> directory" (despite my -D flag)
> or
> 2. "Your data directory is 8.3, but your postmaster is the old 7.4"
> (despite my fully-qualified call to pg_ctl)
>
> Thoughts?
>
> Thanks for helping a newbie,
> Chris
>
> PS: Yeah, I know /backup ain't the place to put my database. But the
> partitions weren't set up right at the beginning, so this is my hack
> for now since I ran out of space.
>

Re: Problem with initdb and two versions on one server?

From
Chris McCormick
Date:
Thank for the good input.

I found my problem. I compiled initially *with* the --disable-rpath
option. When I realised my mistake, I did a make uninstall,
reconfigured, rebuilt, and reinstalled. My post was made when I had
done this and thought I had the settings as stated. However, the
uninstall didn't remove everything (chalk this up to my lack of
linux/build-from-source experience). So I think some of the
not-removed files were still using a disabled rpath and going to the
old 7.4.30 paths.

When I uninstalled and rm'd the directories before restarting the
whole process, it worked.

For the record, I was using bash on CentOS 4.9.

Thanks again,
Chris

On Tue, Feb 28, 2012 at 3:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Chris McCormick <mccormick1@gmail.com> writes:
>>     Because of issues with dump/restore, I am instead setting up a
>> second cluster under a newer version so I can slowly migrate data (I
>> have 7.4.30, and am adding 8.3.18 on the same box). The problem is
>> that when I try to start the new postmaster it complains:
>
>> "FATAL:  database files are incompatible with server"
>> "DETAIL: The data directory was initialised by PostgreSQL version 7.4,
>> which is not compatible with this version 8.3.18."
>
> You are starting the 8.3 postmaster, but giving it a -D setting that
> points at the 7.4 data directory.  The commands you're showing look
> reasonable offhand, but clearly there's something wrong in detail.
>
> One thought that occurs to me is that you might have a PGDATA
> environment variable that points at the old data directory ... the
> explicit -D switches *should* override that, but maybe are failing to?
>
> Also, the documented syntax for pg_ctl is pg_ctl start [switches],
> not what you wrote.  You did not say what the platform is, but some
> versions of getopt() try (with varying degrees of success) to rearrange
> such commands to meet expectations.  Maybe the -D switch is getting
> dropped on the floor somewhere in there.
>
> Another thing worth doing is to examine the PG_VERSION file in each
> data directory, just to make sure it contains what you think.
>
>                        regards, tom lane