Re: reducing the overhead of frequent table locks - now, with WIP patch

On Tue, Jun 7, 2011 at 11:56 AM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> On 06/06/2011 04:43 PM, Robert Haas wrote:
>>
>> On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com>  wrote:
>>>
>>> Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
>>>>
>>>> I've now spent enough time working on this issue now to be convinced
>>>> that the approach has merit, if we can work out the kinks.  I'll start
>>>> with some performance numbers.
>>>
>>> I hereby recommend that people with patches such as this one while on
>>> the last weeks till release should refrain from posting them until the
>>> release has actually taken place.
>>
>> %(at)#!
>>
>> Next time I'll be sure to only post my patches during beta if they suck.
>>
>
> I think Alvaro's point isn't directed at you Robert but at the idea that
> this should be applied to 9.1.

Oh, I get that. I'm just dismayed that we can't have a discussion
about the patch without getting sidetracked into a conversation about
whether we should throw feature freeze out the window. If posting
patches that do interesting things during beta results in everyone
ignoring both the work that needs to be done to get from beta to final
release, and the patch itself, in favor of talking about the release
schedule, then I think at the next developer meeting we're going to
get to hear Tom argue that overlapping the end of beta with the
beginning of the next release cycle is a mistake and we should go back
to the old system where we yell at everyone to shut up unless they're
helping test or fix bugs. Since that overlap is going to (hopefully)
allow this patch to get into the tree ~2-3 months SOONER than it would
have under the old system, I would be unhappy to see it abolished.

Everyone who is arguing for the inclusion of this patch in 9.1 should
take a minute to think about the following fact: If the PostgreSQL
development process does not work for Tom, it does not work. Full
stop. We all know that Tom is conservative with respect to release
management, but we also know that his output is enormous, that he
fixes virtually all of the bugs that *get* fixed, and that our
well-deserved reputation for high quality releases is in large part
attributable to him. We will not be better off if we design a process
that leaves him cold. The fact that Alvaro, Heikki, Andrew, Kevin,
and myself don't like the proposed process either is just icing on the
cake. And I use the term "process" loosely, because what's really
being proposed is the complete absence of any process. The idea of
having a feature freeze some time prior to release is hardly a novel
roadblock that we've invented here at the PostgreSQL Global
Development Group. It's a basic software engineering principle that
has been universally adopted by just about every open and closed
source development project in existence, and with good reason.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company