Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Greg Smith'" <greg(at)2ndQuadrant(dot)com>
Cc: "'Boszormenyi Zoltan'" <zb(at)cybertec(dot)at>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date: 2013-04-03 06:32:52
Message-ID: 005001ce3035$126434c0$372c9e40$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, April 03, 2013 2:23 AM Greg Smith wrote:
> On 4/1/13 5:44 AM, Amit Kapila wrote:
>
> > I think in that case we can have 3 separate patches
> > 1. Memory growth defect fix
> > 2. Default postgresql.conf to include config directory and SET
> Persistent
> > into single file implementation
> > 3. Rearrangement of GUC validation into validate_conf_option
> function.
> >
> > As already there is review happened for point 2 and point 1 is an
> existing
> > code defect fix, so in my opinion
> > Patch 1 and 2 should be considered for 9.3.
>
> They have been considered for 9.3, I just doubt they could get
> committed
> right now. In order for this to go in as part of the very last 9.3
> feature changes (which is where we're at in the development cycle),
> you'd need to have a committer volunteer to take on the job of doing a
> second level of review on it. And then that would have to happen
> without any other issues popping up. That usually is not how it works.
> Normally the first round of committer review finds another round of
> issues, and there's at least one more update before commit. (Note that
> this is exactly what just happened today, with the review from Peter
> Eisentraut)
>
> I'm not saying it's impossible for this feature to go in to 9.3, but
> I'm
> not seeing any committers volunteer to take on the job either. I do
> want to see this feature go in--I'll update it for 9.4 even if you
> don't--but we're already into April. There isn't much time left for
> 9.3. And the security release this week has gobbled up a good chunk of
> committer and packager time unexpectedly, which is just bad luck for
> your submission.
>
> From a process perspective, features that enter the last CF of a
> release that are very close to ready from the start have good odds of
> being committed. You've done an excellent job of updating this in
> response to feedback, but it has involved a long list of changes so
> far.
> It's fair to say this was still a rough feature at the start of CF
> 2013-01, and now it's good but can be usefully polished a bit more.
>
> For something of this size, going from rough feature to commit quality
> normally takes more than one CF. I don't have any obvious errors to
> point out right now. But I think there's still some room to improve on
> this before commit. Andres mentioned on another thread that he thought
> merging some of your ideas with the version Zoltan did was useful to
> look at, and I was thinking of something similar. This is close to
> being ready, and I hope you won't get discouraged just because it's
> probably going to slip to 9.4.

Thank you for keeping me motivated for this patch now and throughout the
last CF by providing valuable suggestions and comments.

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2013-04-03 06:46:27 Re: spoonbill vs. -HEAD
Previous Message Amit Kapila 2013-04-03 06:24:56 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]