Re: pg_config, pg_service.conf, postgresql.conf .... - Mailing list pgsql-hackers

> Quoth pgsql@mohawksoft.com ("Mark Woodward"):
>>> Mark Woodward wrote:
>>>> As a guy who administers a lot of systems, sometimes over the span of
>>>> years,  I can not understate the need for "a" place for the admin to
>>>> find
>>>> what databases are on the machine and where they are located.
>>>>
>>>> Your assertion that this file would "only works for one root-made
>>>> installation on a single filesystem layout" totally misses the point.
>>>> The
>>>> point is that me, a consultant, could find where the database is,
>>>> easily.
>>>> Given a large system, say it has 3 or 4 separate databases on it. How
>>>> do
>>>> you know which is what?
>>>>
>>>
>>> I think you make a good point. However you probably need to include the
>>> location of the server software too (in case you run multiple
>>> versions).
>>> This means there really needs to be a standard location (e.g
>>> /usr/local/etc, /etc ...???? on win32) for this "cluster registration"
>>> file, and you need to list (at minimum):
>>>
>>> PGHOME
>>> DATADIR
>>> PORT
>>> USER
>>
>> I'm not sure that I agree. At least in my experience, I wouldn't
>> have more than one installation of PostgreSQL in a production
>> machine. It is potentially problematic.
>
> Curious.  On our production machines we seldom have less than four
> PostgreSQL instances on any given machine.

"instances" or "installations?" in a production machine, I would keep only
one version of the software and often multiple data "clusters." (I guess
"cluster" is the right word for a physical database directory.)

>
> Perhaps we're wrong and should stop that, but I'd need have to have
> evidence WAY more specific than some devoid-of-details claim of "It is
> potentially problematic."

By problematic, I mean, not only do you need to find the database
"cluster," you would also need to find the correct software for it.

"which postmaster" would not be enough.
>
>>> As Tom hinted, to be effective, this would need to be maintained by
>>> the installation process, otherwise it is just another source of
>>> confusion (like the Oracle site I went to last year where they had
>>> an incorrect /etc/oratab - I wasted *hours* on that....)
>>
>> At least with "oratab" using standards would help.
>>
>> I can tell you, I have tried to find PostgreSQL installs after a
>> power outage and it is hell. If people know there is *a* standard
>> and are expected to use it, they will, they want their systems to
>> run. As it is PostgreSQL has no standard and provides no mechanism
>> to do this.
>
> What is happening is entirely proper.

I completely disagree.

>
> PostgreSQL provides mechanisms; it does NOT impose policies.  This is
> not a mistake; it is intentional.

I 100% absolutely agree with the "mechanism not policies" debate, but in
the case of multiple "clusters" on one machine, there is NO postgresql
standard mechanism to aid this.

>
> 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.