Re: Getting to 9.3 beta

On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote:
> Our final 9.3 commit-fest has has exceeded the two-month mark, so it is
> time to start targeting a date to close it and get to 9.3 beta. I see
> 25 items will needing attention before we can close it:

Very much agreed!

> https://commitfest.postgresql.org/action/commitfest_view?id=17
>
> What is a reasonable timeframe to target for completion of these items?

Here's my take on it:

- Extension templates:
Not ready yet, probably takes a bit more work till committable, last
version got in rather late.
=> move to next fest

- Performance Improvement by reducing WAL for Update Operation:
Not ready yet, some redesigns are recently made, benefits aren't all
that great
=> move to next fest

- Index based regexp search for pg_trgm:
Seems like the patch is undergoing restructuring of the regex access API
=> move to next fest

- Truncate trailing nulls from heap rows to reduce the size of the null
bitmap:
Not sure, benefits don't seem to be all that big for realistic
usecases?
=> move or reject?

- allowing privileges on untrusted languages:
Direction forward seems unclear, discussion required
=> move

- replace plugins directory with GUC
Peter has agreed to boot it to the next fest afaics
(515357F4(dot)6000307(at)gmx(dot)net)
=> move (done)

- sepgsql: name qualified default security label
has been committed by robert, updated CF

- sepgsql: db_schema:search permission and sepgsql: db_procedure:execute
permission:
Not much review afaics.
=> looks unfair, but unless some comitter (robert?) takes it
on I don't see much alternative to booting it to the next fest?

- Patch to compute Max LSN of Data Pages:
I *personally* don't really see a point in including it in postgres,
there doesn't really seem to be any real demand met by the tool
=> reject?

- Make recovery.conf parameters into GUCs:
Nice to see progress, but this seems to be too late for 9.3.
=> move to -next

- pg_retainxlog for contrib:
5102F7C9(dot)6050604(at)gmx(dot)net sums up my opinion of the utility, just
doesn't seem to be reliable enough to be distributed with postgres.
=> reject/redesign?

- REINDEX CONCURRENTLY:
Imo pretty close to being comittable and pretty useful, but it got
redesigned pretty late and it mostly had review from me and fujii and
it could use a bit more input
=> unclear

- built-in/SQL Command to edit postgresql.conf ("SET PERSISTENT" patch):
Different patches afloat, none is really ready. I personally think
Zoltan's patch is more realistic, but ...
=> move

- pg_ctl idempotent option:
looks ready to me
=> commit

- New statistics for WAL buffer dirty writes:
waiting on other for months
=> returned with feedback

- pg_stat_statements: query, session, and eviction identification:
Seems to need at least docs
=> wait for author, seems to be easy enough?

- Json API and extraction functions:
Seems to be committable
=> commit

- psql watch
Waiting on author since 4 days
=> wait or boot?

- User control over psql's error stream
Unclear, there doesn't seem to be much progress and review
=> return with feedback

- plpgsql_check_function:
Tom says (27661(dot)1364267665(at)sss(dot)pgh(dot)pa(dot)us) that even if the approach
can be aggreed uppon it needs quite a bit more work
=> move

- transforms:
I am not sure what solution is proposed for the dependency issue
between shared objects.
There also hasn't been code level review for a while...
=> unclear

- Check file parameters to psql before prompt for password:
No answer to Stephen's review in december
=> return with feedback

- pkg-config for libpq and ecpg:
Issues seem to be fixable easy enough
=> wait

Greetings,

Andres Freund

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