> Bruce Momjian <[EMAIL PROTECTED]> 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.
[snip]
>
> 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.
I am concerned about trying to "protect" users from themselves too
aggresively. A chainsaw that won't cut off a persons arm, is probably not
a useful chainsaw. "Dangerous" tools often need to be to do their job.
>
> 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.
I don't understand this position. There are settings in the configuration
file which can be overridden by the command line already. The problem
already exists.
> 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 don't understand why you say there needs to be "one" switch. Already the
command line overides config settings. All I am arguing is adding one more
command line switch, and four or five GUC settings.
>
> 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.
Ahh, I see the problem, -D is not required if you specify the data
directory in the config file.
postmaster -c /etc/db/postgresql.conf
Is sufficient, however, if "-D" is specified it overides the config file,
just like other parameters. Here are the GUC parameters I want to add:
include = '/etc/postgres/debug.conf'
data_dir = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
> 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'm not sure how the misconception became part of the debate, I did use
one example where you could have multiple databases with the same
configuration, but it in no way the motivation for the patch.
>
> 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?
This I don't agree with. I have been using this for a while and I wrote it
so I can set a standard. "/etc/postgres/postgresql.conf" is a nice
standard.
Yes, during develoment and testing, multiple databases are key, but for
most enterprise deployments, it is boot time initialization script running
one database. The difficulty is that all systems are different, where the
storage is mounted, rights give, etc. The "-C" switch allows me, and
people like me, to define a standard that does not use symlinks, is
independent of the storage layout of the system, and is fairly self
documenting.
I said before, if this functionality gets put into PostgreSQL, I bet that
most VARs and Linux distributions will adopt this as the defacto standard.
It makes configuration much more flexable.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
