To: <josh@agliodbs.com>
Cc: <pgsql-hackers@postgresql.org>
Subject: Re: Overhauling GUCS
In-Reply-To: <200808181235.29983.josh@agliodbs.com> (Josh Berkus's message of
	"Mon\, 18 Aug 2008 12\:35\:29 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <7473.1212625397@sss.pgh.pa.us>
	<Pine.GSO.4.64.0808181250190.17947@westnet.com>
	<87y72u178j.fsf@oxford.xeocode.com>
	<200808181235.29983.josh@agliodbs.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Mon, 18 Aug 2008 20:51:28 +0100
Message-ID: <87tzdi14qn.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Josh Berkus" <josh@agliodbs.com> writes:

> 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.

This I don't understand. If you're managing lots of servers running lots of
software the last thing you want to have to do is write a custom method for
updating the configuration of each service. In that use case you would prefer
to just use rsync/svn/git to push the new config file to all the machines
anyways.

> 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.

These are both use cases which fall in the category I described where you want
to allow users to configure the system through an automated interface. 

We can do that today by generating the automatically generated section and
including that in postgresql.conf as an include file.

>> 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.

The main problem that I've seen described is what I mentioned before: allowing
adjusting the postgresql.conf GUC settings by remote users who don't have
shell access.


-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!