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

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Joshua Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Date: 2011-06-09 13:22:36
Message-ID: BANLkTi=6Xqb8nN33zntyzcFN6dgRSRbtEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 9, 2011 at 2:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> I have asked that we maintain the Reasonableness we have always had
>> about how the feature freeze date was applied. An example of such
>> reasonableness is that if a feature is a few days late and it is
>> important, then it would still go into the release. An example of
>> unreasonableness would be to close the feature freeze on a
>> predetermined date, without regard to the state of the feature set in
>> the release. To date, we have always been reasonable and I don't want
>> to change the process in the way Robert has suggested we should
>> change.
>
> Now you're putting words in my mouth.  I wouldn't want to put out a
> release without a good feature set, either, but we don't have that
> problem.  Getting them out on a fairly regular schedule without a
> really long feature freeze has traditionally been a bit harder.  I
> believe that over the last few releases we've actually gotten better
> at integrating larger patches while also sticking closer to the
> schedule; and I'd like to continue to get better at both of those
> things.  I don't advocate blind adherence to the feature freeze date
> either, but I do prefer to see deviations measured in days or at most
> weeks rather than months; and I have a lot more sympathy for the
> "patch submitted and no one got around to reviewing it" situation than
> I do for the "patch just plain got here late" case.

Can we make this the last post on this topic please?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2011-06-09 13:30:17 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Robert Haas 2011-06-09 13:13:16 Re: reducing the overhead of frequent table locks - now, with WIP patch