Re: Permanent settings - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Permanent settings
Date
Msg-id 20080221093000.GH8138@svr2.hagander.net
Whole thread Raw
In response to Re: Permanent settings  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Permanent settings  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Permanent settings  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Re: Permanent settings  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
On Wed, Feb 20, 2008 at 06:17:37PM -0500, Aidan Van Dyk wrote:
> * Josh Berkus <josh@agliodbs.com> [080220 18:00]:
> > All,
> > 
> > I think we're failing to discuss the primary use-case for this, which
> > is one reason why the solutions aren't obvious.
>  
> > However, imagine you're adminning 250 PostgreSQL servers backing a
> > social networking application.  You decide the application needs a
> > higher default sort_mem for all new connections, on all 250 servers.
> >  How, exactly, do you deploy that?
> > 
> > Worse, imagine you're an ISP and you have 250 *differently configured*
> > PostgreSQL servers on vhosts, and you need to roll out a change in
> > logging destination to all machines while leaving other settings
> > untouched.
> 
> But, from my experience, those are "pretty  much" solved, with things
> like rsync, SCM (pick your favourite) and tools like "clusterssh,
> multixterm", rancid, wish, expect, etc.
> 
> I would have thought that any "larger enterprise" was familiar with
> these approaches, and are probably using them already to
> manage/configure there general unix environments

What makes you think that all environments are unix environments? MOst
large enterprises have multiple operating systems to manage.


> > We need a server-based tool for the manipulating postgresql.conf, and
> > one which is network-accessable, allows updating individual settings,
> > and can be plugged into 3rd-party server management tools.  This goes
> > for pg_hba.conf as well, for the same reasons.
> > 
> > If we want to move PostgreSQL into larger enterprises (and I certainly
> > do) we need to make it more manageable.
> 
> 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?

Do you know of any cross-platform tool that is capable of dealing with the
PostgreSQL configuration file in a context sensitive manner? Meaning that
it doesn't just treat it as a big file, but you can actually do "for all
these 32 servers, change work_mem to 2Mb"? If so, I'd like to know which
one beause I could *raelly* use that one right now.

//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Permanent settings
Next
From: Magnus Hagander
Date:
Subject: Re: Permanent settings