Re: PostgreSQL configuration

> Tom Lane wrote:
>> pgsql@mohawksoft.com writes:
>> > I am neither suggesting nor implementing any change in the current
>> default
>> > behavior of PostgreSQL. I am merely adding features that would make it
>> > easier to do things like configure from a centralized directory which
>> is
>> > different than the data directory, the ability to included
>> > "sub-configuration" like specific tuning or debug info, and to write a
>> > usable PID file for standard UNIX admin scripts.
>>
>> Well, let's take it one piece at a time here.
>> The whole idea of having multiple command-line switches to pick config
>> and data separately bothers me.  ISTM this would mostly create great new
>> opportunities to shoot yourself in the foot (by accidentally picking the
>> wrong combination), without nearly enough benefit to outweigh the risk.
>> Possibly this perspective is somewhat developer-centric --- I'm sure
>> I manually start postmasters far more often than the average person.
>> But then this whole discussion seems of interest only to people with
>> outlier requirements; the existing setup works fine for the average user
>> with only one Postgres installation.
>>
>> Could we compromise on just adding #include functionality?  ISTM that
>> would cover the desire for separate config and data directories.  You
>> could keep a postgresql.conf file in each data directory that simply
>> says
>>     #include /etc/postgres/debug.conf
>> and likewise for other config files.  Doesn't that accomplish what you
>> want?
>
> As I remember, there were two threads in the 7.4 discussion:
>
>     http:/momjian.postgresql.org/cgi-bin/pgpatches2
>
> The discussions are the top-most threads.

The threads I am talking about took place about a year or two ago.
February 2003 sounds about right.

>
> One issue was having the config file, postgresql.conf, drive the PGDATA
> location.  The second issue was putting all the config files,
> postgresql.conf, pg_hba.conf, and pg_ident.conf in a separate directory,
> so it was easier to backup, easier to know which files to edit, and
> easier to symlink it to some other location.

Most DBA/Admins, myself included, don't like symlinks.

>
> On the issue of having postgresql.conf point to the data directory, that
> basically add a level of indirection between the config file and the
> data file, and I know some are concerned that there could be a
> configuration error that could corrupt the database.  It is basically
> putting the config file first, and letting the data directory derive
> from that, rather than pointing to the data directory and finding the
> config file in there.

This is a phylosophical argument about software configuration: How do you
configure software, in configuration files or known files within a
directory. I prefer everything relative from a configuration file.

>
> A third option just mentioned is adding an #include capability to the
> config file.  That gives per-line control over the file contents.  We
> already have the ability to include a list of database/user/group names
> in pg_hba.conf.

That is easy enought.

>
> A fourth idea, where someone just posted a patch, was to have the config
> directory and data directory independent and add flags to point to each
> separately.  I think lots of folks didn't like that because forgetting
> to specify the config directory would give you a running postmaster with
> different config values from previous times you did specify the config
> directory.  That just seems too error-prone.

I have 2 huge problems with using the data directory as the location of
the configuration:

(1) Backup and sharing of configuration state is not obvious.
(2) There is no self documenting equivilent using the data directory. This
directory can be *anywhere* on the system. If using a standardized
configuration, the install becomes obvious.

>
> 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.
>
> My personal opinion is that we move the config files in /data/etc, and
> allow admins to move that directory somewhere else with symlinks.  If we
> want to add #include capability too, that would help things.
>

I wish I could impress on you the distaste the average admin has for
symlinks. If you knew how much DBAs and sys-admins hated symlinks, you
wouldn't think of them as a solution. To most, a symlink is used when the
software has no other viable option. When and admin needs to use a symlink
to configure software, they view this as a cop-out.