On Thu, Dec 11, 2014 at 11:59:58AM -0500, Robert Haas wrote:
> The problem is that, on the one hand, we have a number of serious
> problems with things that got committed and turned out to have
> problems - the multixact stuff, and JSONB, in particular - and on the
> other hand, we are lacking in adequate committer bandwidth to properly
> handle all of the new patches that come in. We can fix the first
> problem by tightening up on the requirements for committing things,
> but that exacerbates the second problem. Or we can fix the second
> problem by loosening up on the requirements for commit, but that
> exacerbates the first problem. Promoting more or fewer committers is
> really the same trade-off: if you're very careful about who you
> promote, you'll get better people but not as many of them, so less
> will get done but with fewer mistakes; if you're more generous in
> handing out commit bits, you reduce the bottleneck to stuff getting
> done but, inevitably, you'll be trusting people in whom you have at
> least slightly less confidence. There's an inherent tension between
> quality and rate of progress that we can't get rid of, and the fact
> that some of our best people are busier than ever with things other
> than PostgreSQL hacking is not helping - not only because less actual
> review/commit happens, but because newcomers to the community don't
> have as much contact with the more senior people who could help mentor
> them if they only had the time.
Great outline of the tradeoffs involved in being more aggressive about
committing. I do think the multixact and JSONB problems have spooked
some of us to be slower/more careful about committing.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
