Re: Getting to beta1

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: jd(at)commandprompt(dot)com
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting to beta1
Date: 2010-03-18 19:20:58
Message-ID: 4BA27D1A.2040407@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joshua D. Drake wrote:
> As usual, the postgresql.conf is entirely too full. We should ship with
> the top 15.

Maybe, but what we should do is ship, and then talk about this again
when it's appropriate--earlier in the release cycle. Let me try and cut
this one off before it generates a bunch of traffic by summarizing where
this is stuck at.

We started this release with a good plan for pulling off a major
postgresql.conf trimming effort that I still like a lot (
http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Auto-Tuning
) The first step was switching over to a directory-based structure that
allowed being all things to all people just by selecting which of the
files provided you put into there. We really need the things initdb
touches to go into a separate file, rather than the bloated sample, in a
way that it's easy to manage; if you just drop files into a directory
and the server reads them all that's the easiest route. Extending to
include the top 15 or whatever other subset people want is easy after that.

Now, that didn't go anywhere in this release due to development focus
constraints, but I'm willing to take "has what we can advertise as
built-in replication" as a disappointing but acceptable substitute in
lieu of that. (rolls eyes) I think it will fit nicely into the "9.1
adds the polish" theme already gathering around the replication features
being postponed to the next release.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-03-18 19:43:03 pgsql: Prevent the injection of invalidly encoded strings by PL/Python
Previous Message Greg Smith 2010-03-18 18:49:28 Re: Ragged latency log data in multi-threaded pgbench