Skip site navigation (1) Skip section navigation (2)

Re: management of large patches

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: management of large patches
Date: 2011-01-03 08:54:53
Message-ID: 4D218EDD.9020407@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
> - MERGE
> - checkpoint improvements
>   

As far as these two go, the state of MERGE is still rougher than I would 
like.  The code itself isn't too hard to read, and that the errors that 
are popping up tend to be caught by assertions (rather than just being 
mysterious crashes) makes me feel a little better that there's some 
defensive coding in there.  It's still a 3648 line patch that touches 
grammar, planner, and executor bits though, and I've been doing mainly 
functional and coding style review so far.  I'm afraid here's not too 
many committers in a good position to actually consume the whole scope 
of this thing for a commit level review.  And the way larger patches 
tend to work here, I'd be surprised to find it passes through such a 
review without some as yet unidentified major beef appearing.  Will see 
what we can do to help move this forward more before the CF start.

The checkpoint changes I'm reworking are not really large from a code 
complexity or size perspective--I estimate around 350 lines of diff, 
with the rough version I submitted to CF2010-11 at 258.  I suspect it 
will actually be the least complicated patch to consume from that list, 
from a committer perspective.  The complexity there is mainly in the 
performance testing.  I've been gearing up infrastructure the last 
couple weeks to automate and easily publish all the results I collect 
there.  The main part that hasn't gone through any serious testing yet, 
auto-tuning the spread interval, will also be really easy to revert if a 
problem is found there.  With Simon and I both reviewing each others 
work on this already, I hope we can keep this one from clogging the 
committer critical path you're worried about here.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2011-01-03 08:58:26
Subject: Re: contrib/snapshot
Previous:From: Brar PieningDate: 2011-01-03 07:19:29
Subject: Visual Studio 2010/Windows SDK 7.1 support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group