Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: reducing the overhead of frequent table locks - now, with WIP patch |
Date | |
Msg-id | BANLkTi=EBnTm8iN821SZa1VNV_sVUJZe7w@mail.gmail.com Whole thread Raw |
In response to | Re: reducing the overhead of frequent table locks - now, with WIP patch ("Joshua D. Drake" <jd@commandprompt.com>) |
Responses |
Re: reducing the overhead of frequent table locks - now, with WIP patch
Re: reducing the overhead of frequent table locks - now, with WIP patch |
List | pgsql-hackers |
On Tue, Jun 7, 2011 at 11:56 AM, Joshua D. Drake <jd@commandprompt.com> wrote: > On 06/06/2011 04:43 PM, Robert Haas wrote: >> >> On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera >> <alvherre@commandprompt.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. >> >> %@#! >> >> 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
pgsql-hackers by date: