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
Re: Permanent settings Re: Permanent settings |
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: