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(at)sss(dot)pgh(dot)pa(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)2ndquadrant(dot)com> wrote:
> On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
> On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
>> On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)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