Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id 515B4531.5020400@2ndQuadrant.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Amit Kapila <amit.kapila@huawei.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
List pgsql-hackers
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
findsanother 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
featureat 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.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: "Erikjan Rijkers"
Date:
Subject: Re: WIP: index support for regexp search
Next
From: Simon Riggs
Date:
Subject: Re: Getting to 9.3 beta