Thread: Running multiple versions

Running multiple versions

From
Nishad Prakash
Date:
I'd like to keep my current installation (8.3.3) alive and running while
installing and running 9.1.2 on the same server.  Can I do this using
only the existing postgres superuser account?  I'd want to create two
different initdb locations, and run the versions on different ports, of
course, but it seems like the superuser's LD_LIBRARY_PATH would be an
issue.  Whichever .../lib dir it points to, would be the only effective
one, and the "other" version's programs wouldn't work.  Is there a way
around this?  Or am I thinking about it all wrong?

nishad




Re: Running multiple versions

From
Scott Marlowe
Date:
On Thu, Jan 5, 2012 at 9:48 PM, Nishad Prakash <prakashn@uci.edu> wrote:
>
> I'd like to keep my current installation (8.3.3) alive and running while
> installing and running 9.1.2 on the same server.  Can I do this using only
> the existing postgres superuser account?  I'd want to create two different
> initdb locations, and run the versions on different ports, of course, but it
> seems like the superuser's LD_LIBRARY_PATH would be an issue.  Whichever
> .../lib dir it points to, would be the only effective one, and the "other"
> version's programs wouldn't work.  Is there a way around this?  Or am I
> thinking about it all wrong?

So assuming all this is done in regular userland. built from source
etc, you'll need to do a couple things.  Each version needs to be
built with a different --prefix.  I prefer something like
--prefix=/home/myusername/pg83 and --prefix=/home/myusername/pg91 and
so on.  This will put the bin, lib etc stuff in your home dir.  Then
in order to do work in one setup or the other, make a you'll need to
set LD_LIBRARY_PATH and PGDATA accordingly for each instance.  It's
often easiest to just have a simple bash script you can run that sets
those so you can be one user or the other at the running of that
script.  so what might be in one would be something like:

# pg8.3.x stuff file:
export PGDATA /home/myuserdir/pg83/data
export PATH=/usr/bin:/home/myuserdir/pg83/bin
export LD_LIBRARY_PATH=/usr/bin:/home/myuserdir/pg83/lib

# pg9.1.x stuff file:
export PGDATA /home/myuserdir/pg91/data
export PATH=/usr/bin:/home/myuserdir/pg91/bin
export LD_LIBRARY_PATH=/usr/bin:/home/myuserdir/pg91/lib

So you'd ru one file or the other to run that database.

Re: Running multiple versions

From
prakashn@uci.edu
Date:
>
> So assuming all this is done in regular userland. built from source
> etc, you'll need to do a couple things.  Each version needs to be
> built with a different --prefix.  I prefer something like
> --prefix=/home/myusername/pg83 and --prefix=/home/myusername/pg91 and
> so on.  This will put the bin, lib etc stuff in your home dir.  Then
> in order to do work in one setup or the other, make a you'll need to
> set LD_LIBRARY_PATH and PGDATA accordingly for each instance.

Thanks for your reply, Scott.  Your suggestion sounds like it would be
fine, but I have a few more questions now.  The docs at
http://www.postgresql.org/docs/9.1/interactive/upgrading.html recommend
using the new version's pg_dumpall to back up the existing cluster for
reload.  In light of your reply, it seems you pretty much *have* to change
the pg superuser's LD_LIBRARY_PATH first.  If that's the case, it seems
the docs should mention that you need to do this, as it's somewhat
non-obvious.

Also, I have root access, so if there's a better solution outside of
regular user land, I'd like to know it.

Finally, the installation docs
(http://www.postgresql.org/docs/9.1/interactive/install-procedure.html)
mention "relocatable installs" and --disable-rpath.  Would *that* be a way
to configure the new version so that calling its .../bin/pg_dumpall (and
other things in bin) would just magically use the right .../lib/
directory?

Thanks,

nishad



Re: Running multiple versions

From
Tom Lane
Date:
prakashn@uci.edu writes:
> Thanks for your reply, Scott.  Your suggestion sounds like it would be
> fine, but I have a few more questions now.  The docs at
> http://www.postgresql.org/docs/9.1/interactive/upgrading.html recommend
> using the new version's pg_dumpall to back up the existing cluster for
> reload.  In light of your reply, it seems you pretty much *have* to change
> the pg superuser's LD_LIBRARY_PATH first.

IMO you should not be depending on LD_LIBRARY_PATH at all; getting it
right in a multi-installation scenario is simply too error-prone.  Each
installation should be built with an rpath specification that points at
its library directory.  End of problem.

--disable-rpath is really only useful when building packages for
distributions that have distro policy against using rpath (because
all shared libraries are supposed to be placed in system directories).
It's not a good idea in any case where you have to put the libraries
in non-system-standard directories.

            regards, tom lane