Bruce Momjian wrote:

Well, in a sense, it trades passing one parameter, PGDATA, for another. I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create pgdata, it adds
an extra level of abstraction to setting up the server.

While this is true, it is not uncommon, and it is more or less expected by most UNIX admins.

Also, there is nothing preventing someone from symlinking the
configuration files from pgdata to somewhere else.

Stop!!! symlinks are not sufficient. When happens when a native Win32 version comes out? there are no symlinks. Also, most of the admins I know don't like to use simlinks as they are not self documenting. Symlinks are "bad."

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.

The problem with that is that you are back to symlinking shared files. Symlinks are a kludge.

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.

I don't see it as very messy, for instance:

postmaster -C /etc/postgres/postgresql.conf -D /RAID0/postgres -p 5432
postmaster -C /etc/postgres/postgresql.conf -D /RAID1/postgres -p 5433

That looks like a real clean way to run multiple PostgreSQL servers on the same box using the same configuration files.

And, if you specify pgdata in postgresql.conf, it prevents you from
using that file by different postmasters.

Not true, command line parameters, as a rule, override configuration file defaults.

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 you are making it too complicated.

I wouldn't remove the default configration set, it would be useful as a failsafe or maintainence feature.



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to