> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
