Re: pg_config, pg_service.conf, postgresql.conf ....

> Mark Woodward wrote:
>> > If you require a policy, then YOU are free to choose the policy that
>> > YOU need. You're not forced to accept other peoples' policies that
>> > may conflict with things in your environment.
>>
>> The problem is that there is no mechanism through which one can
>> implement
>> policy. You are left to "roll your own" each and every time. A mechanism
>> provided, but not enforced, by postgresql would go a LONG way toward
>> enabling a coherent policy.
>
> Unless you can have +80% of sites using the default, it isn't worth it
> and is more confusing than if you had never created it at all. What is
> wrong with defining an environment variable in /etc/profile?
>
It isn't just "an" environment variable, it is a number of variables and a
mechanism. Besides, "profile," from an admin's perspective, is for
managing users, not databases.

OK, think of this, this is an actual site:

I have three PostgreSQL database clusters on one server. A general purpose
web service cluster that has all the web databases in it. I have a
geographical database that has a U.S. street map database. I have a third
which has a large music database on it.

The geo and the music database are rebuilt periodically and tested off
line. They are built and indexed, then tested at the office, and the
physical cluster is uploaded to the server, where the specific postmaster
processes are stopped, swapped, and restarted.

Now, the pg_service.conf, is a HUGE plus for our process. When I work that
into the coding spec, it makes testing the offline code easier because we
no longer have to reconcile connection differences between lab and colo.

Now, we have an environment that has multiple database clusters and server
processes on one machine. How do you manage them? PostgreSQL has no
facility to make this easier.

Similar to pg_service.conf, I am suggesting (the concept has evolved with
discussion) a pg_clusters.conf (name not important) that performs a
similar job as pg_services, but is used to bring up multiple postmaster
processes on one box. Currently, there is no standard way to manage this.

PostgreSQL will continue to perform as it currently does, but a PostgreSQL
"blessed" methodology of managing multiple clusters can be added to it.
Individual processes can still be started and stop independently. Database
clusters that are not in the pg_clusters file can still be created and
started.

I think Chris said it right, I don't want to make policy, I would to
provide functionality. I know my service environment is not unique, and so
what if it is only about 10% (or less) of the PostgreSQL users? There is a
need for this, and it is a valuable "enterprise" level feature. DB admins
will recognize and use this feature. It makes a lot of sense if you stand
back and think of the admin process instead of the core database.

Here's the jist of what I see:

pg_clusters.conf
>>>>>>>>
[GEO]
DPATH=/vol01/pg_geo
PORT=5434

[ICDMDB]
DPATH=/vol01/pg_icdmdb
PORT=5433

[GENERAL]
DPATH=/vol02/pg_users
PORT=5432
<<<<<<<<<

Now, we should be able to modify pg_ctl to do something like this:

pg_ctl -C GEO start
pg_ctl -C ICDMDB start

or

pg_ctl startall