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

Started by Robert B. Easterabout 25 years ago3 messages
#1Robert B. Easter
reaster@comptechnews.com

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/ ------------

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert B. Easter (#1)
Re: Considerations for running current cvs pgsql and pgsql release on same machine?

"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

#3Robert B. Easter
reaster@comptechnews.com
In reply to: Tom Lane (#2)
Re: Considerations for running current cvs pgsql and pgsql release on same machine?

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/ ------------