Re: location of the configuration files - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: location of the configuration files
Date
Msg-id 200302141733.h1EHXgl19321@candle.pha.pa.us
Whole thread Raw
In response to Re: location of the configuration files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: location of the configuration files
Re: location of the configuration files
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to
> > postmaster.
> 
> Wait one second.  You are blithely throwing in a PGCONFIG variable
> without any detailed proposal of exactly how it will work.  Does
> that override a PGDATA environment variable?  How do they interact?

I am just throwing out ideas. I don't think we are near interaction
issues yet.

I think the big question is whether we want the default to install the
configs in a separate directory, pgsql/etc, or just allow the
specification of a separate location.  Advantages of pgsql/etc are
initdb-safe, and easier backups.

I do think PGCONFIG would be helpful for the same reason that PGDATA is.
However, there is clearly a problem of how does data_dir interact with
PGDATA.

The big question is whether PGDATA is still our driving config variable,
and PGCONFIG/-C is just an additional option, or whether we are moving
in a direction where PGCONFIG/-C is going to be the driving value, and
data_dir is going to be read as part of that.


> Also, please note Kevin Brown's nearby arguments against using PGDATA
> at all, which surely apply with equal force to a PGCONFIG variable.
> Now, I don't buy that Kevin's arguments are enough reason to break
> backwards compatibility by removing PGDATA --- but I think they are
> enough reason not to introduce a new environment variable.  PGCONFIG
> wouldn't offer any backwards-compatibility value, and that tilts the
> scales against it.

Weren't you just showing how you set environment variables to easily
configure stuff.  If you use a separate configure dir, isn't PGCONFIG
part of that?

> > 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.
> 
> Good thought, but you're assuming that initdb knows where the config
> files will eventually live.  If we do that, then moving the config
> files breaks the installation.  I think it will be fairly common to
> let initdb drop its proposed config files into $PGDATA, and then
> manually place them where they should go (or even more likely,
> manually merge them with a prior version).  Probably better to force
> datadir to be an absolute path in the config file.  (In fact, on safety
> grounds I'd argue in favor of rejecting a datadir value taken from the
> config file that wasn't absolute.)

Maybe.  Not sure.

> > 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 agree with none of this.  This is not improvement, this is only change
> for the sake of change.  The packagers will do what they want to do
> (and are already doing, mostly) regardless.

Well, it is a step forward in terms of initdb-safe and easier backups.
Several people said they liked that.  I thought you were one of them.

This is back to the big question, who drives things in the default
install, config file or pgdata.

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


pgsql-hackers by date:

Previous
From: "XIE, Rong"
Date:
Subject: help me!!
Next
From: Robert Osowiecki
Date:
Subject: Views and unique indicies optimisation