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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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-08 04:33:26
Message-ID: 201106080433.p584XQv28880@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> 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?

One more thing --- when Tom applied that patch during 8.3 beta it was
with everyone's agreement, so the policy should be that if we are going
to break the rules, everyone has to agree --- if anyone disagrees, the
rules stand.

In this case, several people early felt we should stick with the rules
--- at that point, there should have been no further discussion of
slipping things into 9.1.

Discussion takes energy, and discussing slipping things into 9.1 after
anyone objects is just wasting our valuable time.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-08 05:02:42 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Bruce Momjian 2011-06-08 04:19:21 Re: reducing the overhead of frequent table locks - now, with WIP patch