Re: PostgreSQL configuration

Tom Lane wrote:
> Well, the patch says that the command line switch wins, which is
> consistent with what we do for other command line switches (they all
> override the equivalent postgresql.conf entries).  This does seem a
> bit at variance with the stated goal of making the configuration more
> clearly documented, though :-(.  

Hmm...well, think of it as a tool.  It makes it *possible* to make the
configuration more clearly documented, and in fact makes it easy to do
so, but doesn't guarantee safety in all cases.

> If you actually use the capability then
> your config file will be lying to you about where things are.

Of course.  Just like your config file is lying about any configuration
option that is overridden on the command line.

I don't see why this is a problem, unless we intend to change the way
the entire GUC system works.

> It's worth pointing out in this connection that for the most part
> I think people are moving *away* from using command line switches;
> it's better to set the value in postgresql.conf, both for documentation
> reasons and because that way you have some chance of changing the value
> via config file update and SIGHUP.  The only way to change a value on
> the command line is to restart the postmaster.  Plus, if you're using a
> distribution-supplied init script to start the postmaster, it's hard to
> get any switches in without hacking the script anyway.

Now this raises a very interesting problem.  Namely, what happens if
you use the -C option to the postmaster as is being advocated, then
change the datadir entry in the config file, and send SIGHUP to the
postmaster?  Ooops.  Score one for Tom.  :-)

> Most of these objections also apply to values obtained from environment
> variables (the exception is that postgresql.conf can override
> environment variables).

To be honest, I think the use of the PG_DATA environment variable is the
biggest impediment to "self documentation" - the postmaster should not
use it.

The reason is that if PG_DATA is used to specify the location of the
data directory, you won't be able to find out where a running
postmaster's data directory is located without doing some heavy-duty
investigation.  Not all operating systems make it possible to determine
the values of a particular process' environment variables.

By requiring that the data directory be specified on the postmaster
command line, it becomes possible to always determine where a
postmaster's data directory resides just by looking at the ps output.


Now, I know you guys who do heavy duty development make use of PG_DATA.
I see no problem with having the code in postmaster that looks at
PG_DATA be surrounded by a #ifdef that is active whenever you're doing
development work.  But it should *not* be active on a production system.



Oh, as to the safety issue of a config file not properly corresponding
to a given data directory, that seems easy enough to solve: if a file
(call it "magic" for the purposes of discussion, though perhaps a better
name would be "do_not_remove" :-)  ) exists in the data directory, then
the value of a configuration variable (call it "magic", too) must match
the contents of that file.  If the values don't match then the postmaster
will issue an error and refuse to start.  If the file doesn't exist then
no "magic" configuration option need exist in the config file, and the
postmaster will start as usual.  So any administrator who wants to make
sure that a configuration file has to explicitly be targetted at the data
directory can do so.  End result: if you use the -D option on the command
line with an inappropriate -C option, the postmaster will refuse to run.



-- 
Kevin Brown                          kevin@sysexperts.com