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: