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

Re: CF3+4 (was Re: Parallel query execution)

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CF3+4 (was Re: Parallel query execution)
Date: 2013-01-17 07:19:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 16, 2013 at 1:51 PM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>wrote:

> At 2013-01-16 02:07:29 -0500, tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> >
> > In case you hadn't noticed, we've totally lost control of
> > the CF process.
> What can we do to get it back on track?
> I know various people (myself included) have been trying to keep CF3
> moving, e.g. sending followup mail, adjusting patch status, etc.
> I want to help, but I don't know what's wrong. What are the committers
> working on, and what is the status of the "Ready for commiter" patches?
> Is the problem that the patches marked Ready aren't, in fact, ready? Or
> is it lack of feedback from authors? Or something else?
ISTM that even committers are often overwhelmed with the work, their own as
well as that of reviewing other's patches and committing them. Especially
when a patch is large or touches core areas, I can feel the significant
work that the committer has to do even after some help and initial review
from CF reviewers. On the other hand, if the patches are not committed in
time, we loose context, interest dies down and when the patch is actually
picked up by a committer who is often not involved in the original
discussion, many points need to be revisited and reworked.

Would it help to step up a few developers and create a second line of
committers ? The commits by the second line committers will still be
reviewed by the first line committers before they make into the product,
but may be at later stage or when we are in beta. I thought of even
suggesting that the master branch will contain only commits by the first
line committers. We then maintain a secondary branch which also have
commits from the second line committers in addition to all commits from the
master branch. The first line committers can then cherry pick from the
secondary branch at some later stage. But not sure if this will add more
overhead and defeat the problem at hand.

My 2 cents on this difficult topic.


Pavan Deolasee

In response to


pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2013-01-17 07:49:47
Subject: Re: Hot Standby conflict resolution handling
Previous:From: Abhijit Menon-SenDate: 2013-01-17 07:15:52
Subject: Re: CF3+4

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