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

On Wed, 22 Feb 2006, Mark Woodward wrote:

> > Mark Woodward wrote:
> >
> >> 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.
> >>
> >
> > I agree with you for production environments, but for development, test,
> > support (and pre-sales) machines there are reasonable requirements for
> > several.
>
> Oh, sure, for dev, margeting, etc. It doesn't matter. When you have to
> manage a thousand systems, standards save tons of work.
> >
> > Even if you have only one installation - something to tell you *where*
> > the binaries are installed is convenient - as there are quite a few
> > common locations (e.g. packages installing in /usr or /usr/local, source
> > builds in /usr/local/pgsql or /opt/pgsql). I've seen many *uncommon*
> > variants: (e.g. /usr/local/postgresql, /usr/local/postgresql-<version>,
> > /usr/local/pgsql/<version>, ...).
> >
> > Admittedly, given that the binaries are likely to be in the
> > cluster-owners default PATH, it is not as hard to find them as the data
> > directory. However, this is all about convenience it would seem, since
> > (for many *nix platforms) two simple searches will give you most of what
> > is needed:
> >
> > $ locate postmaster
> > $ locate pg_hba.conf
> >
>
> That's not the issue.
> I find it frustrating sometimes because when I describe one scenario,
> people debate it using other scenarios. Maybe I lack the communications
> skills to convey the problem accurately.

I don'tn think it is that.  I think it's to some extent that you are
starting from a basis that hasn't yet been agreed upon.

First, you should show that your scenario is reasonable. I haven't seen a
reason to assume that the configuration file will be more up to date than
other documentation of the setup. Without that, the theoretical benefit of
the configuration is not fully realized, and in fact could be negative
(for example, what if in your second scenario it is the important db
that's not in the config).

Second, you should show that it belongs in the main package. I think you
could write this without touching the main package. There's then a
question of whether having it in the main package has any negative effect
on people that aren't using it (which includes opportunity cost of
features that might be lost because they don't fit the scenario -- for
example, if someone does have multiple versions of postgresql, does this
preclude a feature to make their administration better) and a question of
whether there are any pieces that must be in the main package.

I think this is a reasonable idea because it can help suggest a way of
doing this to people that might otherwise be doing it by the seat of their
pants, but that's a somewhat different argument. I don't think that I'd
trust the configuration file to be correct if I couldn't trust the admin
to be doing a good job, and to me that includes at least marginally
reasonable documentation. I think that having some system for doing this
(whether it's in the main package or not) is better than multiple people
writing their own.  I am not sure whether having it in the main package
doesn't have a small negative effect on people that need for other reasons
to do their own thing but I haven't looked at it seriously. But since I
don't have time to do it, I'm not going to expect someone else to do it if
they disagree.