Re: PostgreSQL configuration

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Obviously, we need to do something. There are just too many people who
> want improvement in this area. The question is what changes to make.

As far as I've seen in this thread, there's only *one* person arguing
for change, and even he isn't advocating changing the default behavior.
So why are you of the opinion that we need to make radical changes in
the default behavior? Which is what the proposals you've suggested are.

I haven't seen anything that involves changing the default behavior that
would not make it materially harder to run multiple copies of PG, and
especially would make it materially harder to create a test installation
without needing root privileges to do the install. Anything that pushes
config files into fixed places means you need root.

The whole discussion reminds me quite a bit of Tom Lockhart's patch to
specify WAL file location on the postmaster command line. That one
unfortunately degenerated into a religious war :-( which it seems we are
coming perilously close to here as well. But I think the issues are
very similar --- convenience of setup versus probability of accidentally
setting up the wrong thing. The potential downside to the WAL location
business was a lot worse than what we face for config, but it's still a
real risk. Mark Kirkwood pointed out the risk of starting a production
server with the fsync=off setting you use for a test database. Another
example is starting server A with the pg_hba.conf settings you mean to
use with server B, and thereby allowing the wrong set of people access
to server A; in the worst case scenario that'd be a major security
breach.

My general feeling about it is that adding additional postmaster command
line switches is not the way to go, especially not when those switches
can specify things that might be subtly incompatible with other switch-
selected things. That's why I don't like the -C versus -D business.
It's too easy to make a mistake if you are starting the postmaster
manually, and it's too hard to handle if you are starting the postmaster
from an init script (since generally users aren't supposed to edit init
scripts directly, no?). There should be just *one* switch. From a
pure functionality point of view it wouldn't matter much whether it was
-C or -D, as the system could be designed to find either from the other.
But we have a longstanding precedent that it is -D and you find the
config from that. I don't think we should lightly cast aside backwards
compatibility just to reverse the convention.

I have not heard any argument so far that explains to me why it wouldn't
work fine to leave the postmaster switch set as-is (-D only), and expect
people who want centralized config to set up the config files inside
that data directory to be dummies that point to master config files
elsewhere. You can do that today with symlinks, and for those who
dislike symlinks I'm willing to adopt the part of the patch that allows
"#include"-type functionality. This approach keeps the config-to-data
association stored in the filesystem where it should be, rather than
relying on the DBA to remember to specify the correct -C and -D pair
every time he starts the postmaster. It also allows many-to-one
relationships to work properly. You can easily make multiple data
directories point to the same config files, if that is indeed what you
mean to do. You can't make one config file point to multiple data
directories, so the other way requires both -C and -D on the command
line which is error-prone.

I find no merit in the argument about "I can't remember where the data
directory is". If you can't remember that then how are you going to
remember where the config file is either? The only way is to establish
a personal standard. If you want to have a personal standard about
where the centralized config files are, fine --- you can even add
comments to them to remind you of which data directory(s) each one is
used with. But I don't see that that's fundamentally superior to doing
things in the reverse way.

regards, tom lane