Bruce Momjian <[EMAIL PROTECTED]> writes:
> My point is that folks with multiple postmasters may not want to use
> PGDATA, but for folks who have single postmasters, it makes things
> easier and less error-prone.
Actually, for multi postmasters too. I have little shell-environment
config files that switch my entire world view between different source
trees and installation trees, for example this one sets me up to mess
with the 7.2 branch:
STDPATH=${STDPATH:-$PATH}
STDMANPATH=${STDMANPATH:-$MANPATH}
PGSRCROOT=$HOME/REL7_2/pgsql
PGINSTROOT=$HOME/version72
PATH=$PGINSTROOT/bin:/opt/perl5.6.1/bin:$STDPATH
MANPATH=$PGINSTROOT/man:$STDMANPATH
PGLIB=$PGINSTROOT/lib
PGDATA=$PGINSTROOT/data
PMOPTIONS="-p 5472 -i -F"
PMLOGFILE=server72.log
export PGSRCROOT PGINSTROOT PATH MANPATH PGLIB PGDATA STDPATH STDMANPATH
export PMOPTIONS PMLOGFILE
After sourcing one of these, I can use pg_ctl as well as a half dozen
other convenient little scripts that do things like remake and reinstall
the backend:
#!/bin/sh
pg_ctl -w stop
cd $PGSRCROOT/src/backend
make install-bin
startpg
or this one that fires up gdb on a crashed backend:
#!/bin/sh
# Usage: gdbcore
cd $HOME
CORES=`find $PGDATA/base -name core -type f -print`
if [ x"$CORES" != x"" ]
then
ls -l $CORES
fi
if [ `echo "$CORES" | wc -w` -eq 1 ]
then
exec gdb $PGINSTROOT/bin/postgres "$CORES"
else
exec gdb $PGINSTROOT/bin/postgres
fi
This is vastly less error-prone than keeping track of the various
related elements in my head.
Now, it's certainly true that I could still make this work if I had
to explicitly say -D $PGDATA to the postmaster. But that would clutter
my ps display. I am happy with -p as the ps indicator of which
postmaster is which; I don't want more stuff in there.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
