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

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(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-02 20:53:05
Message-ID: 515B4531.5020400@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-04-02 21:02:37 Re: Getting to 9.3 beta
Previous Message Erikjan Rijkers 2013-04-02 20:36:22 Re: WIP: index support for regexp search