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

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?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +