Re: Permanent settings

On Wed, Feb 20, 2008 at 03:56:38PM -0800, paul rivers wrote:
> Tom Lane wrote:
> >Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> >
> >>* Josh Berkus <josh(at)agliodbs(dot)com> [080220 18:00]:
> >>
> >>>We need a server-based tool for the manipulating postgresql.conf, and
> >>>one which is network-accessable, allows updating individual settings,
> >>>
> >
> >
> >>Do we need to develop our own set of "remote management" tools/systems,
> >>or possibly document some best practices using already available "multi-
> >>server managment" tools?
> >>
> >
> >Indeed. If Josh's argument were correct, why isn't every other daemon
> >on the planet moving away from textual configuration files?
> >
> >IIRC, one of the arguments for the config include-file facility was to
> >simplify management of multiple servers by letting them share part or
> >all of their configuration data. One of the things that bothers me
> >considerably about all the proposals made so far in this thread
> >(including mine) is that they don't play very nicely with such a
> >scenario. Putting a setting into one file that contradicts one made in
> >some other file is a recipe for confusion and less admin-friendliness,
> >not more.
> >
>
> If you're interested in comments from the peanut gallery, we run
> hundreds of instances of nearly equal numbers of oracle, sql server,
> postgres, mysql.
>
> IMHO oracle has the most polish here, with its pfile/spfile business
> (excluding listener management, which is still pretty primitive, esp
> compared to the equivalent of what pg_hba.conf offers). SQL Server is
> close, with the internal table sysconfigures, but some things do get
> stashed in the registry. You can programatically edit this across the
> network, so it's not so bad.

It used to be that Oracle didn't have this, IIRC. And it's often quoted as
one of the reasons why people choose MSSQL over it - simply because it made
things easier.

> To date, this approach has worked without any problems. In our case,
> there is a very uniform layout for everything, which is what makes this
> work. postgresql.conf/my.cnf start from general templates, there are
> standard locations for everything, there are shell functions to fetch
> details about any instance from a master list, etc. So while some team
> members would be happy if Pg were more Oracle-esque, it's not a *major*
> issue for us.

Yeah, as long as you have that level of control, that method will work. In
a "typical environment" in many enterprises you simply don't have that
level of control. Your machines may come pre-installed by the vendor, but
you are still expected to manage and maintain them. That means you need
some interface that deals with the configuration on a per-setting basis,
not per-complete-configuration basis.

//Magnus