Re: location of the configuration files

OK, here is an updated proposal. I think we have decided:

Moving postmaster.pid and postmaster.opts isn't worth it.

We don't want per-file GUC variables, but assume it is in
the same config directory as postgresql.conf. I don't
see any valid reason they would want to put them somewhere
different than postgresql.conf.

So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to
postmaster.

Regarding Tom's idea of replacing data_dir with a full path during
initdb, I think we are better having it be relative to the config
directory, that way if they move pgsql/, the system still works.
However, if the config directory is in a different lead directory path,
we should replace it with the full path, e.g. /usr/local/pgsql/data and
/usr/local/pgsql/etc use relative paths, ../data, while /etc/postgresql
and /usr/local/pgsql/data get an absolute path.

My idea is to introduce the above capabilities in 7.4, and keep the
config files in /data. This will allow package folks to move the config
files in 7.4.

I also think we should start telling people to use PGCONFIG rather than
PGDATA. Then, in 7.5, we move the default config file location to
pgsql/etc, and tell folks to point there rather than /data. I think
there is major value to getting those config files out of the initdb
creation area and for backups.

I am now wondering if we should add PGCONFIG and move them out of data
all in the same release. Not sure if delaying the split is valuable.

---------------------------------------------------------------------------

Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Ok, if we're going this far already, tell me exactly why we have three config
> > files. Why not really Unify things and fulfil the full promise of Grand
> > Unified Configuration by rolling hba and ident into postgresql.conf. Is
> > there a compelling reason not to do so?
>
> Lack of backwards compatibility; unnecessary complexity. Unifying those
> files would create a big headache in terms of having to unify their
> syntax. And there are some basic semantic differences too. For
> instance, order matters in pg_hba.conf, but not in postgresql.conf.
>
> Another reason not to do it is that there are differences in the
> security requirements of these files. postgresql.conf probably doesn't
> contain anything that needs to be hidden from prying eyes, but I'd be
> inclined to want to keep the other two mode 600.
>
> ---
>
> Okay, I've been laying low all day, but here are my thoughts on the
> discussion:
>
> I do see the value in being able to (as opposed to being forced to,
> please) keep hand-edited config files in a separate location from
> the machine-processed data files. We have already gone some distance
> in that direction over the past few releases --- there's much less in
> the top $PGDATA directory than there once was. It makes sense to let
> people keep hand-edited files away from what initdb will overwrite.
>
> I would favor a setup that allows a -C *directory* (not file) to be
> specified as a postmaster parameter separately from the -D directory;
> then the hand-editable config files would be sought in -C not -D. In
> the absence of -C the config files should be sought in -D, same as they
> ever were (thus simplifying life for people like me who run many
> postmasters and don't give a darn about FHS ;-)).
>
> I don't see any great value in a separate postgresql.conf parameter for
> each secondary config file; that just means clutter to me, especially
> if we add more such files in future. I am also distinctly not in favor
> of eliminating the PGDATA environment variable; that reads to me as
> "we are going to force you to do it our way rather than the way you've
> always done it, even if you like the old way".
>
> To make the RPM packagers happy, I guess that the default -C directory
> has to be settable via configure. We do not currently have a default
> -D directory, and I didn't hear anyone arguing in favor of adding one.
> So that leaves the following possible combinations that the postmaster
> might see at startup, for which I propose the following behaviors:
>
> 1. No -C switch, no -D switch, no PGDATA found in environment: seek
> postgresql.conf in the default -C directory established at configure
> time. Use the 'datadir' specified therein as -D. Fail if postgresql.conf
> doesn't define a datadir value.
>
> 2. No -C switch, no -D switch, PGDATA found in environment: use $PGDATA
> as both -C and -D. (Minor detail: if the postgresql.conf in the $PGDATA
> directory specifies a different directory as datadir, do we follow that
> or raise an error? I'd be inclined to say "follow it" but maybe there
> is an argument for erroring out.)
>
> (In all the following cases, any environment PGDATA value is ignored.)
>
> 3. No -C switch, -D switch on command line: use -D value as both -C and -D,
> proceed as in case 2.
>
> 4. -C switch, no -D switch on command line: seek postgresql.conf in
> -C directory, use the datadir it specifies.
>
> 5. -C and -D on command line: seek postgresql.conf in -C directory,
> use -D as datadir overriding what is in postgresql.conf (this is just
> the usual rule that command line switches override postgresql.conf).
>
> Cases 2 and 3 are backwards-compatible with our historical behavior,
> so that anyone who likes the historical behavior will not be unhappy.
> Cases 1 and 4 I think will make mlw and our packagers happy. Case 5
> is just the logical conclusion for that combination.
>
> In all cases, pg_hba.conf and pg_ident.conf would be sought in the
> same directory as postgresql.conf. The other stuff in the toplevel
> $PGDATA directory should stay where it is, IMHO.
>
> I would venture that the configure-time-default for -C should be
> ${prefixdir}/etc if configure is not told differently, while the
> packagers would probably set it to /etc/postgresql/ (ie, the
> config files should live in a subdirectory that can be owned by
> postgres user). I'm not wedded to that though.
>
> Another interesting question is whether the installed-by-default
> postgresql.conf should specify a datadir value, and if so what.
> If initdb installs it, it can and probably should insert the actual
> datadir location the user gave to initdb into the file. But should
> initdb install any config files at all anymore? I'm leaning to the
> thought that initdb should store default config files into $PGDATA
> same as it ever did, and then it's up to the user (or package install
> scripts) to move them to the desired -C directory if appropriate.
> Or I suppose we could add a -C parameter to initdb to tell it where to
> put 'em.
>
> Comments?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073