Обсуждение: Running multiple versions
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
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.
> > 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
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