Triaging the remaining open commitfest items - Mailing list pgsql-hackers

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.

* EvalPlanQual behaves oddly for FDW queries involving system columns

I've been working this one and will deal with any mop-up needed, but
I think probably what ought to happen now is just to commit the small
ctid-transmission hack I posted yesterday and call it good.

* BRIN inclusion operator class

This is Alvaro's turf, obviously.

* PageRepairFragmentation optimization

Heikki's patch, so his to commit or not, though since it's marked
Waiting on Author I'm guessing it's not ready?

* 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.

* KNN-GiST with recheck

Heikki's been dealing with this thread so far, and is surely the best
qualified to decide if it's ready or not.

* GIN fillfactor

I'd like to put this one on Heikki's plate as well, since he's touched
the GIN code more than anyone else lately.

* 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.

* 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.

* 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.

* 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.

* archive_mode=shared/always

Heikki's patch, so his call.

* Sending WAL receiver feedback regularly even if the receiver is under heavy load

This seems to not be ready, but it also seems to be a bug fix, so when
it is ready I think we could commit it.

* Auditing extension

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

* 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.

* parallel mode/contexts

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

* RLS: row-level security, more review

Stephen's baby.

* 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

* 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.

* 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.

* TABLESAMPLE clause

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

* REINDEX xxx VERBOSE

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

* Additional role attributes

Is this ready to commit?  Stephen's call.

* catalog view to pg_hba.conf file

Greg Stark is marked as committer of record on this.

* Add pg_settings.pending_restart column

Peter's patch, his call.


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.
        regards, tom lane