Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: reducing the overhead of frequent table locks - now, with WIP patch
Date
Msg-id 4DEE2A5C020000250003E299@gw.wicourts.gov
Whole thread Raw
In response to Re: reducing the overhead of frequent table locks - now, with WIP patch  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.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


pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: Range Types and extensions
Next
From: Alex Hunsaker
Date:
Subject: Re: [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD