Thread: Problem with initdb and two versions on one server?
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.
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
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. >
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