From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Mon, 18 Aug 2008 12:35:29 -0700
User-Agent: KMail/1.8
References: <7473.1212625397@sss.pgh.pa.us>
	<Pine.GSO.4.64.0808181250190.17947@westnet.com>
	<87y72u178j.fsf@oxford.xeocode.com>
In-Reply-To: <87y72u178j.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200808181235.29983.josh@agliodbs.com>

Greg,

> The entire target market for such a thing is DBAs stuck on hosted
> databases which don't have shell access to their machines. 

That's incorrect.  The main reason for having a port-based API (such as the 
SQL command line) for managing your server is that it makes it much easier 
to manage a large number of servers.  Right now, if you want to survey 
your databases, tables, approx disk space, query activity, etc., you can 
do that all through port 5432.  You can't manage most of your server 
settings that way, and definitely can't manage the *persistent* settings.  
When you're trying to manage 1000 PostgreSQL servers, this is not a minor 
issue.

With the growing "cloud" sector, the lack of easy server parameter 
management is hurting PostgreSQL's adoption for hosted applications.  This 
isn't a new complaint, and is a big part of the reason why 90% of web 
hosts still don't offer PostgreSQL.  I've heard complaints about our 
manageability problems from more vendors than I can count.

HOWEVER, it's completely possible to get a 1st-generation config tool out 
there without first implementing port-based config access.  For one thing, 
there's Puppet.  So that's what I'm intending to do.

> I do think you and others make it less likely every time you throw up
> big insoluble problems like above though. 

It's not an insoluble problem.  It's a political problem; several people 
don't want to add this functionality to the project.

> As a consequence every 
> proposal has started with big overly-complex solutions trying to solve
> all these incidental issues which never go anywhere instead of simple
> solutions which directly tackle the main problem.

What, in your opinion, is "the main problem"?  I'm not sure we agree on 
that.

-- 
--Josh

Josh Berkus
PostgreSQL
San Francisco