Triaging the remaining open commitfest items

I wrote:

* Cube extension kNN support

This is still marked as "needs review", I'm afraid we have to push to 9.6.

* compress method for spgist

Sigh. There was a "Ditto" under this one, but somehow it disappeared
in editing :-(

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, May 13, 2015 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

* fsync $PGDATA recursively at startup

Andres is the reviewer of record on this one. He should either commit it
if he feels it's ready, or bounce it to next CF if not.

I committed the first part of this as
2ce439f3379aed857517c8ce207485655000fc8e. I think that we do not have
design consensus on the rest. I think we should mark this committed,
and if the folks who proposed the further work here still want to
press their case, that should wait for 9.6.

* Abbreviated key support for Datum sorts

I've been assuming Robert would either commit this or not, since he's
been the committer for the predecessor patches.

I'll deal with this.

* Sequence Access Method

Heikki's marked as reviewer, so it's his call as to whether this is ready,
but the impression I have is that there's not really consensus as to
whether the API is good. If not, it's something I think we should push
to 9.6.

I share your concern on this one.

* ctidscan as an example of custom-scan

This basically hasn't gotten any attention, which may mean nobody cares
enough to justify putting it in the tree. We need to either push it to
next CF or reject altogether.

Agreed. I was fine with never committing this. I don't think we have
a requirement that every hook or bit of functionality we expose at the
C level must have an example in core. But other people (you? Simon?)
seemed to want a demonstration in the core repository. If that's
still a priority, I am willing to work on it more for 9.6, but there
is not time now.

* parallel mode/contexts

Robert's patch, his to deal with (likewise for "assessing parallel-safety").

Most of the parallel mode stuff is committed. What's left will have
to wait for 9.6.

Assessing parallel-safety will also need to wait for 9.6.

* Join pushdown support for foreign tables

There doesn't seem to be any current patch linked to this CF item.
If there is a patch to get postgres_fdw to make use of the recently
committed join-path support, I assume it's in need of a rebase anyway.

I think there is a rebased patch around. I think it's just not linked
into the CF thread. I don't think it's committable as is.

* Grouping Sets

I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.

I really feel we didn't give this a fair shake. I'm not saying we
should make up for that by committing it in haste, but not giving
things a fair shake is bad for the project regardless of anything
else.

* TABLESAMPLE clause

I assume we'd better push this to 9.6 at this point.

+1

* REINDEX xxx VERBOSE

Seems like we just need somebody to make a decision on syntax.

I just posted a review of this raising minor points only. If it is
timely revised, I will commit it.

* Additional role attributes

Is this ready to commit? Stephen's call.

-1 for committing this, per discussion earlier today on a thread
that's probably not linked into the CF app.

* catalog view to pg_hba.conf file

Greg Stark is marked as committer of record on this.

I am doubtful whether this is ready.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-05-13 11:38:27 -0400, Tom Lane wrote:

Looking at what remains open in the current commitfest:

* fsync $PGDATA recursively at startup

Andres is the reviewer of record on this one. He should either commit it
if he feels it's ready, or bounce it to next CF if not.

The more important part of this has been committed by Robert. The other
part, while also important in my opinion, has by now slipped 9.5.

I've moved it.

* Manipulating complex types as non-contiguous structures in-memory

This one's mine of course. I've been hoping to get more independent
performance testing than it's gotten, but time grows short. I'm inclined
to just go ahead and push it in.

I'm a bit hesitant about performance regressions around it. And I'd
obviously rather not see the macros but the inline version ;). But I
think overall we're in a better position with it, than without. If it
turns out to have bad edge cases performancewise, we can still "turn it
off" in plpgsql without much problems. If we, preferrably, can't find a
better solution for the performance problem.

* Grouping Sets

I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.

This has been in a limbo for a very long time. I'm right now working
with Andrew getting it into a a committable shape. I'm not 100% sure
we'll succeed for 9.5, but it deserves a chance. If it doesn't make it
into 9.6, I plan to get into 9.6 soon after the branch opens.

* Additional role attributes

Is this ready to commit? Stephen's call.

Not yet ready in my opinion.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom, all,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

* Optimization for updating foreign tables in Postgres FDW

I concur with Stephen's assessment that this doesn't look well designed.
I think we should just mark it RWF for now.

I had meant to do that already, sorry about that, done now.

* iteration over record in plpgsql

I fear this one slipped through the cracks --- it's marked Waiting on
Author in the CF app, but it looks like Pavel did submit an updated
version after that marking was made. However, it's not a terribly
significant feature and there was doubt as to whether we want it at
all anyway. Suggest we just punt it to next CF at this point.

I had been interested but also thought it was waiting for a new
version. Doesn't look like I'll have time now.

* Auditing extension

I do not get the impression that there is consensus on this. Push to 9.6?

I've not seen much disagreement about what it provides recently, those
were dealt with a while ago. I agree with Robert that it needs more
work on documentation and comments and I've sent my thoughts about what
to improve in those areas over to David. I've reviewed it in various
forms and am hoping to commit it, unless there are objections.

* RLS: row-level security, more review

Stephen's baby.

I don't have anything pending on this at the moment. Post
feature-freeze I'm planning to spend time on bug hunting, documentation
improvements, etc, for this, UPSERT, and other things. If anyone is
aware of any outstanding issues here, please let me know.

* Additional role attributes

Is this ready to commit? Stephen's call.

I'm pretty happy with the latest version. Would be great for others to
weigh in on if they have any concerns about reserving the 'pg_' prefix
for system roles (or if they're fine with it, that'd be useful to know
too..). I'll also be improving the documentation for it.

* catalog view to pg_hba.conf file

Greg Stark is marked as committer of record on this.

I was hoping to look at that also, as I do think it'd be valuable to
have. The current patch needs rework though. I agree with Peter that
using "keyword_*" arrays is not a good approach and that it'd really be
better to have this in conjunction with a function that users could use
to see what row is returned. I might have time to work on it tomorrow,
if other things fall into place, but it's not going to be without
changes and perhaps that means it has to punt to 9.6.

So there you have it. If everyone would go make decisions on the patches
that they are the most obvious committer for, we could get those taken
care of one way or the other pretty quickly. As for the ones I proposed
pushing to 9.6, any committer who feels differently can pick those up,
else I'll go change their status in the CF app tomorrow or so.

Done, for my part.

Thanks!

Stephen

Andres Freund <andres@anarazel.de> writes:

On 2015-05-13 11:38:27 -0400, Tom Lane wrote:

* Manipulating complex types as non-contiguous structures in-memory

This one's mine of course. I've been hoping to get more independent
performance testing than it's gotten, but time grows short. I'm inclined
to just go ahead and push it in.

I'm a bit hesitant about performance regressions around it. And I'd
obviously rather not see the macros but the inline version ;). But I
think overall we're in a better position with it, than without. If it
turns out to have bad edge cases performancewise, we can still "turn it
off" in plpgsql without much problems. If we, preferrably, can't find a
better solution for the performance problem.

Right, I should have said "absorb Andres' input and then commit". What
I wanted to know was whether there would be objections to committing
this at all.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Robert Haas (robertmhaas@gmail.com) wrote:

On Wed, May 13, 2015 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

* Additional role attributes

Is this ready to commit? Stephen's call.

-1 for committing this, per discussion earlier today on a thread
that's probably not linked into the CF app.

Linked it into the CF, sorry for not doing so earlier.

I'm not going to push it over objections, but I'm certainly hopeful that
there will be further discussion on that thread. For my part, at least,
it's a really nice capability to have that we've been missing for a long
time- I can remember back to the first time I was setting up Nagios and
wondering how in the world I could monitor the system without giving the
Nagios user full superuser rights. I know there are instances out in
the wild that I've set up which are still hacked up to deal with this
lack of capability.

Further, if we don't have something like this, then I'm worried about
people who use the XLOG functions today for monitoring, as we'd end up
having to lock those down to superuser-only, since there isn't anything
between 'public' and 'superuser'.

Thanks!

Stephen

On 05/13/2015 11:38 AM, Tom Lane wrote:

* Grouping Sets

I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.

That makes me sad. I wish you would still try.

Sadly, my plate is full with other stuff, the last few days absorbed
more than my available time.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 13/05/15 17:38, Tom Lane wrote:

* Sequence Access Method

Heikki's marked as reviewer, so it's his call as to whether this is ready,
but the impression I have is that there's not really consensus as to
whether the API is good. If not, it's something I think we should push
to 9.6.

Heikki said he won't have time for this one before freeze so I guess it
can be pushed to 9.6.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-05-13 11:38:27 -0400, Tom Lane wrote:

* parallel mode/contexts

Robert's patch, his to deal with (likewise for "assessing parallel-safety").

Just as a note, a large part of this has been committed.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@anarazel.de> writes:

On 2015-05-13 11:38:27 -0400, Tom Lane wrote:

* parallel mode/contexts

Robert's patch, his to deal with (likewise for "assessing parallel-safety").

Just as a note, a large part of this has been committed.

Right, and Robert commented that he isn't planning to do more here
for 9.5, so probably these CF items should be closed as committed?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, May 13, 2015 at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> writes:

On 2015-05-13 11:38:27 -0400, Tom Lane wrote:

* parallel mode/contexts

Robert's patch, his to deal with (likewise for "assessing parallel-safety").

Just as a note, a large part of this has been committed.

Right, and Robert commented that he isn't planning to do more here
for 9.5, so probably these CF items should be closed as committed?

Already done.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* ctidscan as an example of custom-scan

This basically hasn't gotten any attention, which may mean nobody cares
enough to justify putting it in the tree. We need to either push it to
next CF or reject altogether.

Agreed. I was fine with never committing this. I don't think we have
a requirement that every hook or bit of functionality we expose at the
C level must have an example in core. But other people (you? Simon?)
seemed to want a demonstration in the core repository. If that's
still a priority, I am willing to work on it more for 9.6, but there
is not time now.

If no other people required it again, I don't think this module should
be kept in core and also I'm not favor to push ctidscan to v9.6 development
cycle. It intends to demonstrate custom-scan interface, however, it is
not certain an example always needs to be in-core.
If we split the patch partially, definition below makes sense to implement
out-of-core example module

+#define TIDNotEqualOperator    402
 DATA(insert OID = 2799 (  "<"     PGNSP PGUID b f f    27      27      16 2800
 DESCR("less than");
 #define TIDLessOperator    2799
 DATA(insert OID = 2800 (  ">"     PGNSP PGUID b f f    27      27      16 2799
 DESCR("greater than");
+#define TIDGreaterOperator     2800
 DATA(insert OID = 2801 (  "<="    PGNSP PGUID b f f    27      27      16 2802
 DESCR("less than or equal");
+#define TIDLessEqualOperator   2801
 DATA(insert OID = 2802 (  ">="    PGNSP PGUID b f f    27      27      16 2801
 DESCR("greater than or equal");
+#define TIDGreaterEqualOperator        2802

* Join pushdown support for foreign tables

There doesn't seem to be any current patch linked to this CF item.
If there is a patch to get postgres_fdw to make use of the recently
committed join-path support, I assume it's in need of a rebase anyway.

I think there is a rebased patch around. I think it's just not linked
into the CF thread. I don't think it's committable as is.

I believe he is working to follow up the latest foreign/custom-join
interface on which postgres_fdw expected. One point we like to clarify
is how create_plan_recurse() shall be dealt with.
As Hanada-san posted yesterday, postgres_fdw internally uses
create_plan_recurse() to fetch SQL statement associated with inner /
outer sub-plan, so it will take additional adjustment work even
though he already begin to work.

| IMO it isn't necessary to apply the change onto
| ForeignPath/ForeignScan. FDW would have a way to keep-and-use sub
| paths as private information. In fact, I wrote postgres_fdw to use
| create_plan_recurse to generate SQL statements of inner/outer
| relations to be joined, but as of now SQL construction for join
| push-down is accomplished by calling private function deparseSelectSql
| recursively at the top of a join tree.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:

On 05/13/2015 11:38 AM, Tom Lane wrote:

* Grouping Sets

I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.

That makes me sad. I wish you would still try.

FWIW, I did go look at this patch, and concluded it was not close enough
to ready to try to squeeze it in now. (I think Andres isn't convinced
of that yet, but time grows short, and I quite agree with Robert that
committing almost-ready patches at this stage of the game is a bad idea.)

The good news on this front is that Salesforce has recently taken an
interest in having GROUPING SETS capability, so I should be able to
find more time to work on this over the next month or two. What I am
now hoping for is to work it over and have something ready to push as
soon as the 9.6 branch opens.

What I intend to spend my time on over the next day or so is fixing
the GB18030 conversion problem (bug #12845), which looks like a small
enough task to finish before feature freeze.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 05/13/2015 11:38 AM, Tom Lane wrote:

* Grouping Sets

I had originally promised to be committer for this one, and still want
to go look at it, but Robert's nearby message about not committing stuff
in haste definitely seems to apply.

That makes me sad. I wish you would still try.

FWIW, I did go look at this patch, and concluded it was not close enough
to ready to try to squeeze it in now. (I think Andres isn't convinced
of that yet, but time grows short, and I quite agree with Robert that
committing almost-ready patches at this stage of the game is a bad idea.)

The good news on this front is that Salesforce has recently taken an
interest in having GROUPING SETS capability, so I should be able to
find more time to work on this over the next month or two. What I am
now hoping for is to work it over and have something ready to push as
soon as the 9.6 branch opens.

What I intend to spend my time on over the next day or so is fixing
the GB18030 conversion problem (bug #12845), which looks like a small
enough task to finish before feature freeze.

So you claim the item on the commitfest in the Fall, which effectively
prevents other committers from getting involved, then two days before
the freeze you encourage others to work on it, and a day before the
freeze you say it is too late to apply? And now, all of a sudden, you
are interested in working on this because your employer is interested?

How do I measure the amount of unfairness here?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-05-14 17:10:29 -0400, Tom Lane wrote:

FWIW, I did go look at this patch, and concluded it was not close enough
to ready to try to squeeze it in now. (I think Andres isn't convinced
of that yet, but time grows short, and I quite agree with Robert that
committing almost-ready patches at this stage of the game is a bad idea.)

I think if there's any patch that deserves some leeway it's this
one. It's been been forced into a limbo for nearly half a year; without
leaving Andrew many options.

I've removed the use of GroupedVars and Andrew is right now working on
structural changes. I'm not ready at this point to make a judgement.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 14, 2015 at 11:28:33PM +0200, Andres Freund wrote:

On 2015-05-14 17:10:29 -0400, Tom Lane wrote:

FWIW, I did go look at this patch, and concluded it was not close enough
to ready to try to squeeze it in now. (I think Andres isn't convinced
of that yet, but time grows short, and I quite agree with Robert that
committing almost-ready patches at this stage of the game is a bad idea.)

I think if there's any patch that deserves some leeway it's this
one. It's been been forced into a limbo for nearly half a year; without
leaving Andrew many options.

I've removed the use of GroupedVars and Andrew is right now working on
structural changes. I'm not ready at this point to make a judgement.

I will call for a vote that the freeze deadline be changed if this patch
is rejected to due to time. I might lose the vote, but I am going to
try because if we lose our reputation for fairness, we have lost a lot
more than a week/month of release time.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:

On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote:

The good news on this front is that Salesforce has recently taken an
interest in having GROUPING SETS capability, so I should be able to
find more time to work on this over the next month or two. What I am
now hoping for is to work it over and have something ready to push as
soon as the 9.6 branch opens.

So you claim the item on the commitfest in the Fall, which effectively
prevents other committers from getting involved, then two days before
the freeze you encourage others to work on it, and a day before the
freeze you say it is too late to apply? And now, all of a sudden, you
are interested in working on this because your employer is interested?

[ shrug... ] Andrew had unilaterally removed me as committer from that
patch back in January or so, so it dropped way down my priority list.
I'm willing to move it back up now, but I could do without people
expressing a sense of entitlement to my time. In any case, Andres is
currently the committer of record, and if he decides to push it in the
next 24 hours, I'm not doing anything more to stand in his way than
Robert already did.

How do I measure the amount of unfairness here?

Life is unfair.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 14, 2015 at 05:37:07PM -0400, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote:

The good news on this front is that Salesforce has recently taken an
interest in having GROUPING SETS capability, so I should be able to
find more time to work on this over the next month or two. What I am
now hoping for is to work it over and have something ready to push as
soon as the 9.6 branch opens.

So you claim the item on the commitfest in the Fall, which effectively
prevents other committers from getting involved, then two days before
the freeze you encourage others to work on it, and a day before the
freeze you say it is too late to apply? And now, all of a sudden, you
are interested in working on this because your employer is interested?

[ shrug... ] Andrew had unilaterally removed me as committer from that
patch back in January or so, so it dropped way down my priority list.
I'm willing to move it back up now, but I could do without people
expressing a sense of entitlement to my time. In any case, Andres is

I am trying not to express any entitlement. I do have a problem with
people claiming things that block others. In fact, the reason your name
was taken off was because you were inactive on the patch.
Unfortunately, even though your name was removed, people still thought
of you as owning the patch, and your formidable reputation cemented
that. I feel if you had not gotten involved, that patch would have been
applied long ago, When someone's involvement _prevents_ a patch from
being reviewed or applied, that is the opposite of what we want. I
think this effect is indisputable in this case, which is why I am saying
if we let this patch slip due to time, we are being unfair.

currently the committer of record, and if he decides to push it in the
next 24 hours, I'm not doing anything more to stand in his way than
Robert already did.

Uh, did Robert delay work on the patch in any way?

How do I measure the amount of unfairness here?

Life is unfair.

True, but I have problems with leaders acting in a way that is unfair to
those with less power. Have you considered how demoralizing it is to
work in an unfair environment? Unfairness happens, but as leaders, we
are supposed to try to avoid it, not cause it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 14, 2015 at 2:28 PM, Andres Freund <andres@anarazel.de> wrote:

On 2015-05-14 17:10:29 -0400, Tom Lane wrote:

FWIW, I did go look at this patch, and concluded it was not close enough
to ready to try to squeeze it in now. (I think Andres isn't convinced
of that yet, but time grows short, and I quite agree with Robert that
committing almost-ready patches at this stage of the game is a bad idea.)

I think if there's any patch that deserves some leeway it's this
one. It's been been forced into a limbo for nearly half a year; without
leaving Andrew many options.

+1.

If Andres is going to try and find a way of getting the patch into
9.5, then I think he deserves at least a few extra days. It wasn't as
if Andrew wasn't all over this from early in the cycle.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers