Re: PostgreSQL configuration

> pgsql(at)mohawksoft(dot)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.

Cool.

>
> I can see some value in providing "#include" functionality in
> postgresql.conf (and the other config files too). I'm not convinced
> that it's a must-have, because the desired contents of the config files
> tend to change with each new PG version. But to the extent that you're
> admining multiple clusters of the same version, it would have some use.

Speaking for myself, I like it because I can keep a set of debugging
parameters in a separate file, and only comment out the "include ..." for
production. (Not to mention that multiple databases can use it.)

>
> Moving the PID file out of the data directory is actively dangerous,
> because we use that file as part of the safety interlock against
> starting multiple postmasters in the same data directory. I suppose
> we could offer an option to write a second copy of the PID file at
> a different place, but I'm not seeing what that buys except confusion
> (especially if two postmasters are mistakenly instructed to put their
> copied PID files at the same place).

The patch that I have creates a completly separate PID file from that in
the PGDATA directory. It is used for more compatible UNIX init scripting.
(Obviously on machines with only one database system.)

>
> 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.

This is where I think we disagree. Very much so, in fact. I think having
something like:

/etc/postgres/webdb.conf
In which there is a line:
datadir=/RAID0/postgres

and

/etc/postgres/testdb.conf
In which there is this line
datadir=/RAID1/postgres

Allows for a very standardized, and IMHO, very self documenting installation.

> 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.

Tom, I really disagree here. I really don't know how to convey my feelings
about this, other than banging my head against the wall. I setup, develop
on, and manage a lot of different systems, PostgreSQL is frustrating for
me because I do not always have control over what is what. I have to
deploy systems on machines which I do not get to specify the layout. I do
not know where the various volumes will be. A year later, I will have
completely forgotten, and of course my notes are no where to be found.

One of the reasons I wrote these mods was so I could create a "standard."
All my PostgreSQL systems have an /etc/postgres/postgresql.conf file. I
sit down and know immediately where to look. I can *always* tell a user,
over the phone, run:
"/usr/local/pgsql/bin/postmaster -C /etc/postgres/postgresql.conf"

It *always* works, and when it doesn't it is because something has changed.

It may make it easier for an expert to shoot themselves in the foot, but
it also makes it easier for an expert to make it bullet proof.

>
> 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?
>

The include functionality was added as a result from a debate about this
patch a couple years ago. The Primary purpose of my patch was to have the
configuration in a standard location.