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

On Wed, Jun 8, 2011 at 1:10 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Why do you address this to me? Many others have been committing
> patches against raised issues well after feature freeze.

No one other than you has proposed committing anything nearly as
invasive as this, and the great majority of what we've committed has
been targeted at new regressions in 9.1.

There is a difference between a feature and a bug fix. Sometimes the
distinction is arguable, but this isn't one of those cases. A feature
freeze does not mean an absolute code freeze; it means a freeze on
*features*.

> You do not wish to stop all patches, only those you disagree with. How
> would I know you disagree with a patch without discussing it?
>
> I note that you've claimed *everything* I have discussed is a new
> feature, whereas everything you or others have done is an "open item".
> You can claim that everything I suggest is a dust-up if you wish, but
> who makes it a dust up and why?

I think the people, including me, who feel that it's not a good idea
to commit new features have been very clear about the reasons for
their position - namely, (1) the desire to get the release out the
door in a timely fashion, and (2) the desire to treat everyone's
patches in a fair and even-handed way rather than privileging some
over others. I'm just as much against committing my own features, or
Tom's features, or Alvaro's features as I am against committing your
features - not because I don't like the features (I do) but because I
want to release 9.1 in about a month.

> The point I have made is that I disagree with a feature freeze date
> fixed ahead of time without regard to the content of the forthcoming
> release. I've not said I disagree with feature freezes altogether,
> which would be utterly ridiculous. Fixed dates are IMHO much less
> important than a sensible and useful feature set for our users. MySQL
> repeatedly delivered releases with half-finished features and earned
> much disrespect. We have never done that previously and I am against
> doing so in the future.

So am I. But apparently, we have very different ideas of what that
means. I thought that "making the server shuts down properly, even
if you are using sync rep" was a clear-cut case of correcting a
half-finished feature, but you argued against that change. And I
think that "revamping the locking mechanism so it's faster" is clearly
a new feature, not a repair to something half-finished. I don't
expect it's very realistic to think that everyone is going to agree on
every patch, but we can't agree that bug fixes and features should be
treated differently, or if we can't agree at least in most cases on
what the difference is between one and the other, then we will spend a
lot of time talking past each other.

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