Bruce Momjian wrote:
> I don't think separate params for each config file is good. At the
> most, I think we will specify the configuration _directory_ for all the
> config files, perhaps pgsql/etc, and have pgdata default to ../data, or
> honor $PGDATA. That might be the cleanest.
>
> Of course, that now gives us $PGCONFIG and $PGDATA, and possible
> intraction if postgresql.conf specifies a different pgdata from $PGDATA.
> As you can see, it could get messy.
Uh...why are we having to mess with environment variables at all?
It's one thing for shell scripts to make use of them, but another
thing entirely for an executable like the postmaster to do the same.
Seems logical to me to eliminate the use of $PGDATA in the postmaster
entirely. It usually gets started from a shell script, so let the
shell script pass the appropriate parameter telling the postmaster
where to find the data, or the config files, or whatever.
> And, if you specify pgdata in postgresql.conf, it prevents you from
> using that file by different postmasters.
Not at all. Don't GUC variables that are specified on the command
line override the ones in the configuration file?
> My best guess would be to not specify pgdata in postgresql.conf, and
> have a new $PGCONFIG param to specify the configuration directory, but
> if we do that, $PGDATA/postgresql.conf becomes meaningless, which could
> also be confusing. Maybe we don't allow those files to exist in $PGDATA
> if $PGCONFIG is used, _and_ $PGCONFIG is not the same as $PGDATA. See,
> I am getting myself confused. :-)
I think the solution is real simple:
1. Eliminate the use of $PGDATA in the postmaster. It causes far more headaches than it's worth. Instead, require
that-D be passed on the command line. It's fine if the postmaster *sets* $PGDATA in order to minimize any changes
thatneed to be made elsewhere, but the postmaster should not use it until it sets it. The postmaster right now
readsall the config files (including postgresql.conf) from the directory specified by the -D option. Keep it that
way.
2. Add a GUC variable that specifies where the data is. If this variable is not defined either on the command line
orin the config file, then assume that the data is in the same place as the config file. Obviously files like
PG_VERSIONare associated with the data and not with the config, so they get treated appropriately.
The above addresses *everyone's* concerns that I've seen thus far, I
think. Thoughts?
--
Kevin Brown kevin@sysexperts.com