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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers