Re: Permanent settings - Mailing list pgsql-hackers

On Wed, Feb 20, 2008 at 03:56:38PM -0800, paul rivers wrote:
> Tom Lane wrote:
> >Aidan Van Dyk <aidan@highrise.ca> writes:
> >  
> >>* Josh Berkus <josh@agliodbs.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