Thread: Considerations for running current cvs pgsql and pgsql release on same machine?

I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same 
machine without them conflicting (if possible).  Can someone explain what I 
should look out for when trying to do this?

I assume I'll have to configure --with-pgport=5433 (something other than 
5432).

How will the use of the environment variables PGDATA and PGLIB be affected if 
I have them still pointing at the release version?

I'm wanting to begin keeping an updated pgsql-cvs installation running and 
maybe get active in working on the sources.  Maybe I can start out with 
documentation stuff.  I've been following this list long enough and still 
enjoy it so I want to try towards contributing stuff.

-- 
-------- Robert B. Easter  reaster@comptechnews.com ---------
- CompTechNews Message Board   http://www.comptechnews.com/ -
- CompTechServ Tech Services   http://www.comptechserv.com/ -
---------- http://www.comptechnews.com/~reaster/ ------------

"Robert B. Easter" <reaster@comptechnews.com> writes:
> I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same 
> machine without them conflicting (if possible).  Can someone explain what I 
> should look out for when trying to do this?

I routinely run multiple versions at the same time.  You need a separate
port, install directory, and data directory for each.  Easiest way to do
this is to configure the non-default versions with

./configure --with-pgport=nnn --prefix=/path/to/someplace

to establish their ports and install dirs, and then initdb each version
with the appropriate data directory specified.  A user then doesn't have
to do much except make his PATH point at the PREFIX/bin dir for the
version he wants to use at the moment.

You may also find that you have to pump up your kernel's IPC resource
parameters in order to start up multiple postmasters.

> How will the use of the environment variables PGDATA and PGLIB be
> affected if I have them still pointing at the release version?

They had better have the right values while initdb'ing or starting
each individual version.  There's no good reason to have either one
set in the general environment, or actually to set them at all --- you
can get the same results with command line switches to initdb and
postmaster, with much less chance of bad side-effects.

A tip I find handy is to make sure that the databases available under
each live postmaster have distinct names.  This helps to avoid the
mistake of testing against 7.0.2 when you thought you were testing
against 7.0.3 or current or whatever...

> I've been following this list long enough and still 
> enjoy it so I want to try towards contributing stuff.

Welcome aboard!
        regards, tom lane

On Friday 22 December 2000 22:05, Tom Lane wrote:
> I routinely run multiple versions at the same time.  You need a separate
> port, install directory, and data directory for each.  Easiest way to do
> this is to configure the non-default versions with
>
> ../configure --with-pgport=nnn --prefix=/path/to/someplace
>
> to establish their ports and install dirs, and then initdb each version
> with the appropriate data directory specified.  A user then doesn't have
> to do much except make his PATH point at the PREFIX/bin dir for the
> version he wants to use at the moment.
>
> You may also find that you have to pump up your kernel's IPC resource
> parameters in order to start up multiple postmasters.
>
> > How will the use of the environment variables PGDATA and PGLIB be
> > affected if I have them still pointing at the release version?
>
> They had better have the right values while initdb'ing or starting
> each individual version.  There's no good reason to have either one
> set in the general environment, or actually to set them at all --- you
> can get the same results with command line switches to initdb and
> postmaster, with much less chance of bad side-effects.
>
> A tip I find handy is to make sure that the databases available under
> each live postmaster have distinct names.  This helps to avoid the
> mistake of testing against 7.0.2 when you thought you were testing
> against 7.0.3 or current or whatever...

Thanks for these tips.  I took out all global PG environment variables from 
/etc/profile.  The way I did it, was to make a directory /etc/pgsql.d and in 
there have files pgsql.sh and pgcvs.sh for production and cvs test 
environments.  Each sets up the variables:

# Change these two
PGHOME=/usr/local/pgsql or /home/pgcvs/pgsql
PGPORT=5432 or 5433

PGLIB=$PGHOME/lib
PGDATA=$PGHOME/data
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PGLIB
MANPATH=$MANPATH:$PGHOME/man
PATH=$PGHOME/bin
export PGHOME PGPORT PGLIB PGDATA LD_LIBRARY_PATH MANPATH PATH

These two files are then included into .profile in user directories like:

# Pgsql prod
.. /etc/pgsql.d/pgsql.sh

or

# Pgsql cvs dev
.. /etc/pgsql.d/pgcvs.sh

The cvs development version runs under user pgcvs while the production runs 
under user postgres as normal.  The only little problem about this setup is 
that I can almost just run pgsql.sh and pgcvs.sh to switch between the two 
environments while logged in as a user.  But if I do, PATH, MANPATH and 
LD_LIBRARY path, because they append, don't replace one thing for another.  
I'm sure that can be fixed with some simple bash/awk/sed trick but I haven't 
tried yet.  The next thing is to setup another local-only httpd on port 8080 
or whatever and get another php to compile with the cvs libs so I can test 
web stuff.


-- 
-------- Robert B. Easter  reaster@comptechnews.com ---------
- CompTechNews Message Board   http://www.comptechnews.com/ -
- CompTechServ Tech Services   http://www.comptechserv.com/ -
---------- http://www.comptechnews.com/~reaster/ ------------