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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Joshua Berkus" <josh(at)agliodbs(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Date: 2011-06-07 18:40:44
Message-ID: 4DEE2A5C020000250003E299@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:

> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.

I've worn a lot of hats in the practical end of this industry, and
regardless of which perspective I look at this from, I can't think
of anything so destructive to productivity, developer morale,
meeting deadlines or release quality as "slipping in just one more
item after feature freeze". It's *always* something that someone
feels is so important that it's worth the delay and/or risk, and it
never works out well.

There are a lot of aspects of the development and release processes
on which I can see valid trade-offs and a lot of room for
negotiations and compromise, but having a feature freeze which is
treated seriously isn't one of them. If nobody else was making an
issue of this, I still would be.

There's absolutely nothing personal or political in this -- I just
know what I've seen work and what I've seen cause problems.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2011-06-07 18:42:01 Re: [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
Previous Message Darren Duncan 2011-06-07 18:40:02 Re: Range Types and extensions