Re: Getting to 9.3 beta - Mailing list pgsql-hackers

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,
benefitsaren'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 =>
moveto 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
thatbig 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.6000307@gmx.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'treally 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.6050604@gmx.net sums up my opinion of the utility, just doesn't seem to be
reliableenough 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
itmostly 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,
seemsto  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.1364267665@sss.pgh.pa.us) that even if the approach can be aggreed uppon it
needsquite a bit more work => move
 

- transforms: I am not sure what solution is proposed for the dependency issue between shared objects. There also
hasn'tbeen 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