commitfest 2018-07 - Mailing list pgsql-hackers

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