Обсуждение: So where are we on the open commitfest?
The September commitfest has been drifting sideways for most of this
month. I think it's about time to put it out of its misery, especially
since the next one is due to start in barely more than 2 weeks.
The remaining open items:
* Allow encoding specific character incrementer
This has certainly gotten reviewed. I'm unclear on whether it's
committable or not. Let's either commit it or mark it Returned With
Feedback (Robert?).
* Separating bgwriter and checkpointer
Same for this one.
* pg_last_xact_insert_timestamp
This one is stuck because we don't have consensus on whether it should
be applied. I suggest pushing it forward to the next 'fest to give
Simon a reasonable amount of time to come up with a counterproposal.
(At some point, though, we should commit it if he doesn't provide one.)
* Non-inheritable check constraints
Greg Stark claimed this one for committing a few weeks ago, but has
not done anything visible since then. Greg?
* Range Types
This has certainly had plenty of work done too. If it's not committable
yet, I think we should mark it Returned With Feedback for now.
* WIP: SP-GiST, Space-Partitioned GiST
I was willing to review this as soon as Oleg and Teodor provided more
than no documentation; but none has been forthcoming, and I think Oleg
is on vacation in the Himalayas again. Suggest pushing it to next fest.
* %TYPE and array declaration
Reviewed, don't have any problem marking this as Returned With Feedback.
* prepare plans of embedded sql on function start
This was reviewed and more or less rejected in September. There is a
new patch there that is completely different, hasn't been reviewed,
but was submitted in October. I think we should mark the original patch
as RWF or even Rejected, and put the new patch in as a brand new item
(new title at least) in the next fest.
* unite recovery.conf and postgresql.conf
This one also seems to be lacking consensus more than anything else.
What do we do about that?
regards, tom lane
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > * Allow encoding specific character incrementer > > This has certainly gotten reviewed. I'm unclear on whether it's > committable or not. Let's either commit it or mark it Returned With > Feedback (Robert?). I think it's committable. Let me drum up a round tuit or two. > * Separating bgwriter and checkpointer > > Same for this one. Possibly some discussion here is warranted about the cost of pushing fsync requests from the background writer to the checkpointer. I guess I feel like that's probably not a major concern; it can likely be optimized further if it turns out to be an issue. > * pg_last_xact_insert_timestamp > > This one is stuck because we don't have consensus on whether it should > be applied. I suggest pushing it forward to the next 'fest to give > Simon a reasonable amount of time to come up with a counterproposal. > (At some point, though, we should commit it if he doesn't provide one.) +1 to all of that, including the parenthetical note. > * Non-inheritable check constraints > > Greg Stark claimed this one for committing a few weeks ago, but has > not done anything visible since then. Greg? No comment. > * Range Types > > This has certainly had plenty of work done too. If it's not committable > yet, I think we should mark it Returned With Feedback for now. I have been thinking about looking at committing at least part of this, but thought Heikki might be planning to pick it up. > * WIP: SP-GiST, Space-Partitioned GiST > > I was willing to review this as soon as Oleg and Teodor provided more > than no documentation; but none has been forthcoming, and I think Oleg > is on vacation in the Himalayas again. Suggest pushing it to next fest. +1. > * %TYPE and array declaration > > Reviewed, don't have any problem marking this as Returned With Feedback. +1. > * prepare plans of embedded sql on function start > > This was reviewed and more or less rejected in September. There is a > new patch there that is completely different, hasn't been reviewed, > but was submitted in October. I think we should mark the original patch > as RWF or even Rejected, and put the new patch in as a brand new item > (new title at least) in the next fest. +1. > * unite recovery.conf and postgresql.conf > > This one also seems to be lacking consensus more than anything else. > What do we do about that? AFAIR, the only person objecting is Simon. I'm not necessarily saying that means we should drive it in over his objections, but OTOH there were quite a few people who spoke in favor of it and we shouldn't ignore those voices either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>> * unite recovery.conf and postgresql.conf >> >> This one also seems to be lacking consensus more than anything else. >> What do we do about that? > > AFAIR, the only person objecting is Simon. I'm not necessarily saying > that means we should drive it in over his objections, but OTOH there > were quite a few people who spoke in favor of it and we shouldn't > ignore those voices either. The problem is, it will break tools. I was one of the people that supported Simon in his argument against. Not going to cause a huge stink but it is something to consider. JD > -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
"Joshua D. Drake" <jd@commandprompt.com> writes:
>>> * unite recovery.conf and postgresql.conf
>>>
>>> This one also seems to be lacking consensus more than anything else.
>>> What do we do about that?
>> AFAIR, the only person objecting is Simon. I'm not necessarily saying
>> that means we should drive it in over his objections, but OTOH there
>> were quite a few people who spoke in favor of it and we shouldn't
>> ignore those voices either.
> The problem is, it will break tools. I was one of the people that
> supported Simon in his argument against. Not going to cause a huge stink
> but it is something to consider.
Yeah, but it's those same tools that will benefit from a cleaner
definition. Sometimes it doesn't pay to be slaves to backwards
compatibility.
regards, tom lane
On Fri, Oct 28, 2011 at 4:07 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >>> * unite recovery.conf and postgresql.conf >>> >>> This one also seems to be lacking consensus more than anything else. >>> What do we do about that? >> >> AFAIR, the only person objecting is Simon. I'm not necessarily saying >> that means we should drive it in over his objections, but OTOH there >> were quite a few people who spoke in favor of it and we shouldn't >> ignore those voices either. > > The problem is, it will break tools. I was one of the people that supported > Simon in his argument against. Not going to cause a huge stink but it is > something to consider. Oh, sorry, JD. I had forgotten that you also spoke in favor of leaving it be. Anyway, we just need to make up our mind on what we're going to do and do it. Not talking about it, or talking about it but not making a decision, leads to frustration all around. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > * Separating bgwriter and checkpointer > > Same for this one. Will commit by end of Monday > * pg_last_xact_insert_timestamp > > This one is stuck because we don't have consensus on whether it should > be applied. I suggest pushing it forward to the next 'fest to give > Simon a reasonable amount of time to come up with a counterproposal. > (At some point, though, we should commit it if he doesn't provide one.) +1 > * unite recovery.conf and postgresql.conf > > This one also seems to be lacking consensus more than anything else. > What do we do about that? I'll re-read the thread in detail to see if I can break impasse. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
>> This one also seems to be lacking consensus more than anything else. >> What do we do about that? > > I'll re-read the thread in detail to see if I can break impasse. When we last left it, I pointed out to you that 100% backwards compatibility is impossible: we simply can't maintain recovery.conf as a trigger file and also clean up the broken API. You had no response for how to resolve that. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> * Separating bgwriter and checkpointer >> >> Same for this one. > > Will commit by end of Monday There are plenty of source comments (and probably documents) describing that checkpoint is performed by bgwriter, but the patch that you posted didn't correct them. Are you going to include the change of them in the patch? Or commit separately? >> * pg_last_xact_insert_timestamp >> >> This one is stuck because we don't have consensus on whether it should >> be applied. I suggest pushing it forward to the next 'fest to give >> Simon a reasonable amount of time to come up with a counterproposal. >> (At some point, though, we should commit it if he doesn't provide one.) > > +1 +1 >> * unite recovery.conf and postgresql.conf >> >> This one also seems to be lacking consensus more than anything else. >> What do we do about that? > > I'll re-read the thread in detail to see if I can break impasse. That's very helpful. I'd like to hear what you think we should not change for the backward compatibility, and what we can do. AFAIR you agreed to rename recovery.conf, so I don't guess that you want 100% compatibility. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * Range Types
>>
>> This has certainly had plenty of work done too. �If it's not committable
>> yet, I think we should mark it Returned With Feedback for now.
> I have been thinking about looking at committing at least part of
> this, but thought Heikki might be planning to pick it up.
Yeah, this one is in Heikki's court AFAIK.
I've updated the commitfest items for which there seemed to be no
disagreement. We still have
>> * Allow encoding specific character incrementer (on your head)
>> * Separating bgwriter and checkpointer (on Simon's)
>> * Non-inheritable check constraints (on Greg Stark's)
>> * Range Types (on Heikki's)
>> * unite recovery.conf and postgresql.conf (Simon's on the hook to advance this discussion)
regards, tom lane
On 29.10.2011 06:40, Tom Lane wrote: > Robert Haas<robertmhaas@gmail.com> writes: >> On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> * Range Types >>> >>> This has certainly had plenty of work done too. If it's not committable >>> yet, I think we should mark it Returned With Feedback for now. > >> I have been thinking about looking at committing at least part of >> this, but thought Heikki might be planning to pick it up. > > Yeah, this one is in Heikki's court AFAIK. I'm waiting for Jeff to fix the caching of type metadata in range type functions to work like the corresponding caching in array functions. I believe that's the last outstanding item on that patch. Jeff, can you get around to do that in the next few days? If not, I might go and do it myself, but I'm lazy and would prefer not to ;-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Sat, Oct 29, 2011 at 2:21 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >>> * Separating bgwriter and checkpointer >>> >>> Same for this one. >> >> Will commit by end of Monday > > There are plenty of source comments (and probably documents) describing that > checkpoint is performed by bgwriter, but the patch that you posted > didn't correct > them. Are you going to include the change of them in the patch? Or commit > separately? Yes, I will resolve all your comments either in first commit, or ones immediately following. Thank you again for making those observations. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Oct 28, 2011 at 9:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> * unite recovery.conf and postgresql.conf >> >> This one also seems to be lacking consensus more than anything else. >> What do we do about that? > > I'll re-read the thread in detail to see if I can break impasse. I've added a new comment onto the OP to summarise this. ISTM there is a good way forwards. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > * Non-inheritable check constraints > > Greg Stark claimed this one for committing a few weeks ago, but has > not done anything visible since then. Greg? > Sorry, I had hoped to look at it during pgconfeu but found Amsterdam a bit too distracting. I'm looking at it now. -- greg
> * Non-inheritable check constraints
>
So, this patch got shifted to the next commitfest...
Regards,
Nikhils
On Mon, Nov 14, 2011 at 4:23 PM, Nikhil Sontakke <nikkhils@gmail.com> wrote: >> > * Non-inheritable check constraints >> > > > So, this patch got shifted to the next commitfest... I'm sorry, I had intended to get to it for the last two weekends. I'm not going to wait until the commitfest to look at it. What I want to test is that it behaves sanely when you add and remove children to the inheritance graph. Other than that I expect it should be pretty non-controversial and useful. -- greg