All of the information on the CommitFest app is as accurate as I could
make it now, I made a pass over every open thread there to look for
major changes that hadn't gotten message ID archive links. Since the
official start 13 patches have been committed and 6 bounced out.
Reminder notes have gone out to most of the people who there's something
waiting for, mostly off-list nagging, and several people have already
gotten back to say they're planning to hash out open issues over this
weekend.
Of the 34 patches still waiting for review or their author, there's a
couple of the usual suspects responsible for a good chunk of them.
Greg Smith: 10 patches that troublemaker is meddling with in some
form. I'm clearly not going anywhere this upcoming week, as I've had
"panic over closing of CommitFest in the middle of December" on my
calendar for a while. General plan of attack is:
-Try and break the deadlock over what to do with
pg_last_xact_insert_timestamp (done with that for now)
-Update "Configuration include directory" to fix all of Noah's suggestions
-Make a similar pass over "includeifexists in configuration file", which
is a little cut and paste from the first one and may have some of the
same errors.
-Revisit the "unite recovery.conf and postgresql.conf" from a new
perspective that presumes those two features are coming. I suspect we
can implement some of the "what I'd like is this" requests people wanted
here with these features, to chop away enough edge cases to make this
more tractable.
-Mixed with the bigger above bits, during smaller chunks of time help
rework "pg_terminate_backend and pg_cancel_backend by not administrator
user", "Measuring relation free space", and "Separate pg_stat_activity
into current_query into state and query columns" features to commit
quality.
-Resume slogging through the controversy around "Core extensions
relocation" and see if that goes anywhere.
-Join in on any benchmarking help I can provide for some of Robert's
patches, starting with "Make pgBufferUsage track dirty buffers"
-Continued work with Peter G on pg_stat_statements normalization. I
consider a major feature in the "Performance Release" theme 9.2 has
taken on.
There's a normal sized plate lined up for Robert since he's been keeping
up better; in no particular order:
-More review on the always a new surprise "Fix Leaky Views Problem, again"
-Extra fun with "Tuplesort comparison overhead reduction"
-His own "avoid taking two snapshots per query" and "FlexLocks" improvements
And then Dimitri is on:
-His "Command Triggers"
-Review on "Prep object creation hooks"
-Another likely pass over Robert's "avoid taking two snapshots per query"
Other people in similarly loaded and overlapping lists with the above
include Fujii Masao and KaiGai Kohei. So about half of the open items
are from contributors who have a track record of just coming back for
more every time. It's not like we're going to wonder off based on
whether our submission goes in now or we have to keep chugging along. I
think most of the above is achievable in 9.2.
What I'm happy about is that I'm not seeing any giant controversial
things here, the sort that tend to hit the last CF and then push its
boundary back too. Last year at this time, patches on the table at this
point were things like Extensions, Sync Rep, Per-column collation, and
KNN-gist. Those had the bad mix of "we want this feature for the
relase" and "this is hard". That pushed some of them into early March
before they got committed. I think only Dimitri's Command Triggers has
that sort of potential this time. And I've been talking with him enough
about the plan there to feel it chunks into useful pieces pretty well if
the target feature set has to scale back. We'll have to see if anyone
tries to sneak one of the more complicated things into the final CF.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
