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

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Chris McCormick <mccormick1(at)gmail(dot)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