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

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]

  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 6: Have you searched our list archives?


Reply via email to