To: "Josh Berkus" <josh@agliodbs.com>
Cc: <pgsql-hackers@postgresql.org>
Subject: Re: Overhauling GUCS
In-Reply-To: <200805311144.38056.josh@agliodbs.com> (Josh Berkus's message of
	"Sat\, 31 May 2008 11\:44\:37 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <48409D1E.3070208@agliodbs.com> <16866.1212251015@sss.pgh.pa.us>
	<200805311144.38056.josh@agliodbs.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Sat, 31 May 2008 20:36:54 +0100
Message-ID: <87tzgejmeh.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

> It's my viewpoint based on a lot of user feedback that the current 
> postgresql.conf is fundamentally broken and a major roadblock to PostgreSQL 
> adoption. This was a point with which there was pretty much universal 
> agreement when I talked with people at pgCon.  

Actually as a new DBA when I was first starting out with Postgres I found it
very convenient to have all the common parameters in one place where I could
just uncomment and adjust them. Instead of having to search through
documentation and find the default value from which

> 1 & 2) by not having the settings be defined in a 500-line file, new users 
> would no longer be baffled by scores of settings which probably don't concern 
> them, trying to find the handful of settings which do.

I'm not sure how an empty file is any less "baffling" than one listing the
default value for parameters they don't need yet.

> 3) We'd consolidate the GUC lists down from 3 places to 2, which is one less 
> area to synchronize.  Magnus and I looked to see if it might be possible to 
> generate the docs from the same list, but it's not practical.

This seems like a trivial gain and one which is unlikely to outweigh the pain
of having to massage the info into C data structures.

> 4) By shifting from a model where postgresql.conf is document-formatted and 
> hand-edited to one where it's machine generated, it becomes vastly easier to 
> write simple utilities to manage these settings.  Right now, the big 
> "obstacle" to things like SET PERSISTENT is "how to we preseve the 
> hand-edited comments in the file" -- and the answer is we *don't.*  

What this sounds like is a sly way to try to get rid of postgresql.conf
entirely and replace it with parameters stored in the database so admins would
adjust the parameters using an SQL syntax rather than a text file.

There are pros and cons of such a system but I think for newbie admins that
would be a thousand times *more* baffling. You would have to learn new
commands and have no holistic view of what parameters had been set, what
related parameters might exist. You also have no way to keep the file in a
version control system or sync across servers etc.

> Have you *looked* at postgresql.conf.sample lately, Tom?  It's a disaster.  
> Maintenance is already difficult, and becoming more so as we add settings.

What difficulties?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!