Tom Lane wrote:
> [EMAIL PROTECTED] 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.
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.
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.
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.
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.
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.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
