Pending 9.4 patches

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Pending 9.4 patches
Date: 2014-04-04 19:57:56
Message-ID: 20140404195756.GE26295@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I today tried to cleanup the state of the pending patches a bit. I hope
I haven't bloodied too many toes.

Here's a summary of all patches that aren't either committed, returned
or rejected:

Pending patches waiting for committer are:
c01) Custom Scan APIs
This really seems to need Tom's attention.
c02) cache-only table scan
This unfortunately also seems to need Tom's attention.
c03) ALTER TABLE lock strength reduction
Simon should cleanup the cosmetic issues noticed by Noah and commit
it.
c04) Foreign table inheritance.
No idea. Too big to look.
c05) Widening application of indices.
Is this really ready? I am rather doubtful.
c06) Enable CREATE FOREIGN TABLE (... LIKE ... )
I *personally* don't like some parts of the approach, but a committer
should decide. My concerns are more around aestetics and
maintainability than any "real" problems.
c07) Updatable security barrier views.
This needs a serious look by a committer.
c08) Bugfix for timeout in LDAP connection parameter resolution.
Looks pretty straightforward to me.
c09) Problem with displaying "wide" tables in psql
Not really sure. I wonder if there are situations where the new
output will be more confusing than the old.
c10) PostgreSQL fails to start on Windows if it crashes after tablespace
creation
Looks good to me, trivial code formatting issue.
c11) pg_ctl fails with config-only directory
Not a big fan, but I don't have a better idea.
c12) pg_ctl always uses the same event source
I personally think this is pointless complication. But I am also not a windows person.
c12) "pg_ctl stop" times out when it should respond quickly
c13) PostgreSQL Service on Windows does not start if data directory given is relative path
I unfortunately couldn't convince myself to care enough to have an
opinion on these.

The complicated patches that seem to need serious committer time are:
c07, c01, c02, c04, c05.

My feeling is that 01 and 02 came in pretty darn late in their current
form to be fully considered for 9.4, independent of their state. 07
seems to be somewhat large this late, but there really hasn't been much
change recently.

Pending patches waiting for review are:
r01) Inverse Aggregate Transition Functions
There's some argument about whether a already useful subset should
be committed in 9.4 or whether everything should be in 9.5. The 9.4
thing doesn't seem to be too far away from being ready.
r02) Using indices for UNION
Tom seems to be looking at atm. Not that big.
r03) Optimization in regexp handling in pg_trgm
Unsure whether the complications are worth the gains.
r04) Row-security based on Updatable security barrier views
This one's fate seems to be hard to judge without c07.
r05) WAL rate limiting
I don't think we can get concensus on this for 9.4, thus it
probably should be returned with feedback.
r06) Add min, max, and stdev execute statement time in pg_stat_statement
The discussion here seems to have stalled on the questions which
additional columns should be added. Doesn't look too hard to make
committable once agreement has been reached.
r07) ECPG cursor readahead
I have no friggin idea.
r08) vacuumdb: Add option --analyze-in-stages
Should imo be committed after some absolutely minor cleanup.
r09) transforms
It's a bit sad to see so this patch limping along for more than a
year now. But it still doesn't seem to be ready :(. Peter wrote
more than two months back that he wants to make another pass after
a couple nights of sleep. I'll have a look so there's some
progress, but I don't think it's 9.4 material at this point.
r10) PL/pgSQL Warnings - plpgsql.warn_shadow
I haven't followed, and the thread is too long.
r11) extension_control_path
Minefield.
r12) Create function prototype as part of PG_FUNCTION_INFO_V1
Some potential issues, but it'd reduce the amount extension authors
have to type.
r13) Correctly place DLLs for ECPG apps in bin folder
msvc issue, doesn't seem to be fully ready. Seems like a bug worthy
of fixing tho.
r14) Issue with PGC_BACKEND parameters on Windows
Looks simple enough.
r15) multibyte messages are displayed incorrectly on the client
Seems like a bigger can of worms than its worth.
r16) tests for client programs
Should imo be committed after some simple cleanup.

The bigger things that might have a bearing for 9.4 seem to be: r01,
r04. Lots of the other stuff just need someone paying a bit of
attention.

Waiting for author:
w01) GiST support for inet datatypes
Needs a rebase as noticed today, apparently ready for committer
otherwise.
w02) variant of regclass etc.
Robert noticed some issues today when he wanted to commit.

I hope that we can prune this list to the patches that we think have a
chance for 9.4, so we can avoid delaying the feature freeze. The CF is
officially closed, so the rest really should be returned/moved.

Comments?

Greetings,

Andres Freund

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-04-04 20:29:30 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Tom Lane 2014-04-04 19:36:27 Re: Using indices for UNION.