On Wed, Feb 20, 2008 at 03:56:38PM -0800, paul rivers wrote: > Tom Lane wrote: > >Aidan Van Dyk <[EMAIL PROTECTED]> writes: > > > >>* Josh Berkus <[EMAIL PROTECTED]> [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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
