Well, here we are at the end of July.
here's the current state of Commitfest 2018-07:
*Status summary: *Needs review
<https://commitfest.postgresql.org/18/?status=1>: 83. Waiting on Author
<https://commitfest.postgresql.org/18/?status=2>: 31. Ready for
Committer <https://commitfest.postgresql.org/18/?status=3>: 17.
Committed <https://commitfest.postgresql.org/18/?status=4>: 54. Moved to
next CF <https://commitfest.postgresql.org/18/?status=5>: 8. Rejected
<https://commitfest.postgresql.org/18/?status=6>: 5. Returned with
Feedback <https://commitfest.postgresql.org/18/?status=7>: 2. Total
<https://commitfest.postgresql.org/18/?status=-1>: 200.
At the start of the commitfest I endeavoured privately to encourage some
movement particularly on the oldest items, which a number of people
suggested we should try to focus on. Four of those items have been
successfully disposed of.
There has also been some movement on these old items (arbitrarily
defined as those that are 5 or more CFs old):
https://commitfest.postgresql.org/18/528/ "Fix the optimization to skip
WAL-logging on table created in same transaction"
we have a proposed fix from Heikki / Kyatoro. That seems to be the
consensus solution, although it's somewhat invasive. I hope we keep
moving on this.
https://commitfest.postgresql.org/18/713/ "Correct space parsing in
to_timestamp()"
There seems to be close to a consensus on the solution, Alexander has
asked for some more documentation.
https://commitfest.postgresql.org/18/944/ "Logical decoding of two-phase
transactions"
There are significant ongoing discussions on a way forward
https://commitfest.postgresql.org/18/1004/ "SERIALIZABLE with parallel
query"
Masahiko Sawada has posted a review, and we're waiting on the author.
https://commitfest.postgresql.org/18/1141/ "Full merge join on
comparison clause"
Ashutosh posted a review, the author has responded with updated patches,
further review is needed
https://commitfest.postgresql.org/18/1160/ "Improve geometric types"
Ongoing discussion, possibly close to a commit.
https://commitfest.postgresql.org/18/1264/ "Exclude partition constaint
checking in query execution plan for partitioned table queries"
a.k.a. "Secondary index access optimizations "
David Rowley posted a very substantial review, including a patch with an
alternative approach. The author has not responded
No real progress has been made on the following old items:
https://commitfest.postgresql.org/18/669/ "pgbench - allow to store
query results into variables"
This items is marked RFC and Stephen has claimed it as committer. It's
been around for 9 CFs now.
https://commitfest.postgresql.org/18/931/ "Protect syscache from
bloating with negative cache entries"
I suggested at the start of the CF that this item should possibly be
marked RWF, but that wasn't universally agreed to. However, nothing
further has happened.
https://commitfest.postgresql.org/18/1001/ "Convert join OR clauses into
UNION queries"
Silence since April.
https://commitfest.postgresql.org/18/1085/ "XML XPath default namespace
support"
Has been RFC since January but nobody has claimed it.
https://commitfest.postgresql.org/18/1124/ "Incremental sort"
Nothing since the patch was rebased at the end of May
https://commitfest.postgresql.org/18/1138/ "Improve compactify_tuples
and PageRepairFragmentation"
Not clear that it will make any significant improvement. Nothing
substantial since April.
https://commitfest.postgresql.org/18/1166/ "Fix LWLock degradation on NUMA"
this item has been marked RFC since September, but nobody has claimed it.
https://commitfest.postgresql.org/18/1252/ "Foreign Key Arrays"
In May author stated he was having trouble rebasing the patch and
devising tests, and asked for help, but there has been no response
It appears that a combination of concentrating on Release 11 issues and
northern summer vacation time has meant we havem't accomplished very
much with this CF, at least in terms of getting actual commits and
clearing up[ the backlog. I'm not sure that I would recommend repeating
the experiment.
Early on I published some stats of patch sizes, which I obtained by
doing some pretty ugly screen scraping. All the data underlying the CF
should be public, and it would possibly make sense to provide some API
for querying it directly.
Sometimes thde app sees an attachment in the email thread and marks it
as the latest patch, but in a number of cases it isn't - it's either not
a patch at all or occasionally something to be applied after the main
patch is applied. I realize it has to use heuristics but it might be
well to allow some sort of manual override of the "latest patch".
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
