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]