Tom Lane wrote:
> I don't see any great value in a separate postgresql.conf parameter for
> each secondary config file; that just means clutter to me, especially
> if we add more such files in future. I am also distinctly not in favor
> of eliminating the PGDATA environment variable; that reads to me as
> "we are going to force you to do it our way rather than the way you've
> always done it, even if you like the old way".
The scripts needn't ignore PGDATA at all. Only postmaster. Since the
vast majority of people start the postmaster from a script, this winds
up being a minor issue, except for the fact that without PGDATA
administrators will be able to count on looking at the output of 'ps'
to determine where the postmaster is looking for either the config
file or the data directory. In other words, they'll have somewhere to
start from without having to poke through scripts that might not even
have been used (what happens when a user defines PGDATA and starts a
postmaster? The administrator will have to go to more extreme
lengths, like using lsof, to figure out where the data directory is.
Not all systems have such tools).
> Comments?
I agree with your assessment for the most part, except for PGDATA.
There's no good reason I can think of for the postmaster to look at
it. It's fine if it sets it for processes it forks to inherit, but it
shouldn't pay attention to it on startup. Some people might complain,
but there's little difference in doing a "postmaster -D $PGDATA" and
just "postmaster", and people who are starting things by hand
hopefully aren't so inflexible as to demand that PGDATA remain treated
as-is. People who really care can create a simple little 'pm.sh'
script that simply does a "postmaster -D $PGDATA", which will save
them typing even over just doing a "postmaster" from the command line.
--
Kevin Brown kevin@sysexperts.com
