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

On Wed, Jun 8, 2011 at 5:19 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > My point was that we have in the past implemented performance changes
>> > to increase scalability at the last minute, and also that our personal
>> > risk perspectives are not always set in stone.
>> >
>> > Robert has highlighted the value of this change and its clearly not
>> > beyond our wit to include it, even if it is beyond our will to do so.
>>
>> So, at the risk of totally derailing this thread -- what this boils
>> down to is a philosophical disagreement.
>>
>> It seems to me (and, I think, to Tom and Heikki and others as well)
>> that it's not possible to keep on making changes to the release right
>> up until the last minute and then expect the release to be of high
>> quality.  If we keep committing new features, then we'll keep
>> introducing new bugs.  The only hope of making the bug count go down
>> at some point is to stop making changes that aren't bug fixes.  We
>> could come up with some complex procedure for determining whether a
>> patch is important enough and non-invasive enough to bypass the normal
>> deadline, but that would probably lead to a lot more arguing about
>> procedure, and realistically, it's still going to increase the bug
>> count at least somewhat.  IMHO, it's better to just have a deadline,
>> and stuff either makes it or it doesn't.  I realize we haven't always
>> adhered to the principle in the past, but at least IMV that's not a
>> mistake we want to continue repeating.
>
> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
> user I talked to at Linuxworld mentioned high vacuum freeze activity and
> simple calculations showed the many read-only queries could cause high
> xid usage.  Fortunately we already had a patch available and Tom applied
> it during beta.  It was an existing patch that took on new urgency
> during beta.
>
> Robert's point above is that it isn't so much making the decision of
> whether something should slip past the deadline, but the time-sapping
> discussion of whether something should slip, and the frankly disturbing
> behavior of some in this group to not accept a clear consensus,
> therefore prolonging the discussion of slippage far longer than
> necessary.
>
> Basically, if you propose something, and it gets shot down due to
> procedure, accept that unless you have some very good _new_ reason for
> continuing the discussion.  If you don't like that, then you are not
> going to do well in our group and maybe this isn't the group for you.
>
> I think we are going to need to be much more forceful about this, and if
> the threat that someone has commit rights and therefore we can't ignore
> them, we will have to reconsider who can commit to this project.  Do I
> need to be any clearer?

You are very clear, but as to why, I am not sure.

On Monday, realising that Robert had discovered something of massive
potential benefit to the community, I asked Tom to take a look at the
patch to see if I could get his interest in including it in this
release. I did that out of pure altruism; how could I possibly benefit
from highlighting the work of another person, another company?

Tom has agreed with me that making tuning proposals during beta is
acceptable. In this case, he thinks it is too risky to apply. In fact,
I agreed, having reviewed the patch myself, suggesting a much simpler,
non-invasive patch instead (a new reason, as you say). I then
immediately accepted his decision to exclude any patch involving
locking from further consideration.

Given the level of potential benefit, I don't have a problem tapping
Tom on the shoulder to review it and see if it is tweakable. At no
point have I discussed applying the patch myself, nor have I ever even
considered it. The main point is that in his hands a task can be done
in days, not the months others have quoted. You can read that as
respect and optimism, or you can see chaos and disrespect, but that is
all in the eye of the beholder.

As a result of this, I've been insulted, told I have no respect for
process and even suggested there was a threat of patch war. None of
that is reasonable or anywhere close to truth. If there has been a
time sapping discussion, it is because people have jumped to
conclusions and responded irrationally. To be honest, I'm completely
surprised by all of that. I had no idea that me asking Tom a question
was perceived as a denial of service attack on the community, nor that
it would result in the comments made to me and about me.

As long as I am allowed the freedom to speak in this forum then I will
speak up for PostgreSQL users, committer or not. As long as I'm a
committer, I will take responsibility for the code and seek to improve
it and fix it according to the community process.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services