Re: PostgreSQL configuration

> pgsql(at)mohawksoft(dot)com wrote:
>> > The bottom line to me is that config versus data ought to be a one-to-
>> > many relationship, at least if you accept the premise that shared
>> config
>> > is reasonable at all. Putting a datadir spec inside the config file
>> > makes it impossible to share config files across datadirs, and so that
>> > seems to conflict with the argument (which is being made in support of
>> > this very same patch) that sharable config is good. On the other
>> hand,
>> > if you make data point to config then you have a very natural way to
>> > manage the one-to-many relationship.
>> >
>> > Separate -C and -D would make sense if it were a many-to-many
>> > relationship (ie, you could sensibly use many different configs with
>> the
>> > same data dir), but the case for multiple configs with one data dir
>> > seems pretty weak to me, and outweighed by the risk factors.
>>
>> I hear "risk" but what risk?
>
> OK, you look at your postgresql.conf file, and it says the data is in
> /var/data, but the postgresql.conf file was found via PGDATA, so it is
> ignored, and the directory is /var/local/pgsql. That seems confusing
> because someone looking at the file sees the wrong information.

Given enough time and tinkering, anyone can screw up an installation of
anything.
>
> For me, having a config file that both "is found" with ignored values,
> and another mode where the config file points to everything seems
> strange. Does any other OS project do this?

Almost all of the open source services allow you to override the default
settings in the configuration file with a command line option. Anyone can
make a case for almost any system which seems confusing. I think we all
agree that all configration should be made in a configuration file,
however we all recognize that, sometimes, an easy to use command line
option to override the configuration settings is helpful for many reasons.

>
> What if someone does -C /var/data/postgresql.conf, and postgresql.conf
> say to use /usr/local/data for data, what do we do?

Command line is always the last authority, followed by the configuration
file, followed environment, followed by any hard coded defaults.

Sure, you can come up with problems in every system, but that's easy. You
guys are very fond of symlinks, do you know how problematic they are?
Their behavior is very much dependent on the application and the options
used. I can tell you how often I've seen "unexpected" behavior with
symlinks. Either the backup system just backs up the link when you think
it should copy the data, or copies the data when it should copy just the
link.