Scariest patch tournament, PostgreSQL 11 edition

PostgreSQL hackers and community at large, previously I wrote:

In the spirit of the season, the Release Management Team would like to
gather your thoughts on Fear, Risk and Data Corruption for features in
PostgreSQL 11. What patch or patches committed in this cycle do you
think have the highest probability of causing problems of any sort for
users?

Now that the beta is out and everybody is hopefully back from PGCon, we
would like to invite you to propose your scariest patches:

https://docs.google.com/forms/d/e/1FAIpQLSeE20Zzny34U6cEk20HYlQN9vsJzmT9maiLYCp1BdNHYvYCPA/viewform

(ref. /messages/by-id/20180426160612.nxfscncq4yiqmzyg@alvherre.pgsql )

Thank you, and happy bug hunting,

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hackers,

One month of beta testing has flown by, and enough bugs have already
been reported that your view of what patches are scariest might have
matured. You still have a few days before we close the contest at the
end of the month. Let us know what patches you think are scariest:

https://docs.google.com/forms/d/e/1FAIpQLSeE20Zzny34U6cEk20HYlQN9vsJzmT9maiLYCp1BdNHYvYCPA/viewform

Thanks,

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Mon, Jun 25, 2018 at 6:52 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

Hackers,

One month of beta testing has flown by, and enough bugs have already
been reported that your view of what patches are scariest might have
matured. You still have a few days before we close the contest at the
end of the month. Let us know what patches you think are scariest:

https://docs.google.com/forms/d/e/1FAIpQLSeE20Zzny34U6cEk20HYlQN
9vsJzmT9maiLYCp1BdNHYvYCPA/viewform

Thanks,

Is there a summary of the results of the previous rounds? I didn't see any
announcements of them. I've been trying to find some crash recovery
torture testing to do for v11 release, but can't find features to focus on
which might be scariest from a WAL perspective.

Cheers,

Jeff

On Mon, Jun 25, 2018 at 3:52 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

One month of beta testing has flown by, and enough bugs have already
been reported that your view of what patches are scariest might have
matured. You still have a few days before we close the contest at the
end of the month. Let us know what patches you think are scariest:

Is there going to be an announcement of the results?

--
Peter Geoghegan

On 2018-Jun-25, Jeff Janes wrote:

Is there a summary of the results of the previous rounds? I didn't see any
announcements of them. I've been trying to find some crash recovery
torture testing to do for v11 release, but can't find features to focus on
which might be scariest from a WAL perspective.

I processed the answers today after many delays. Here's [one way of
looking at] the results:

commit │ title │ committer │ points
─────────────┼────────────────────────────────────────────────────────────────┼──────────────────┼────────
499be013de6 │ Support partition pruning at execution time │ Alvaro Herrera │ 6
8b08f7d4820 │ Local partitioned indexes │ Alvaro Herrera │ 6
cc415a56d09 │ Basic planner and executor integration for JIT. │ Andres Freund │ 5
8561e4840c8 │ Transaction control in PL procedures │ Peter Eisentraut │ 5
86f575948c7 │ Allow FOR EACH ROW triggers on partitioned tables │ Alvaro Herrera │ 4
e2f1eb0ee30 │ Implement partition-wise grouping/aggregation. │ Robert Haas │ 4
3de241dba86 │ Foreign keys on partitioned tables │ Alvaro Herrera │ 4
2f178441044 │ Allow UPDATE to move rows between partitions. │ Robert Haas │ 4
f49842d1ee3 │ Basic partition-wise join functionality. │ Robert Haas │ 4
16828d5c027 │ Fast ALTER TABLE ADD COLUMN with a non-NULL default │ Andrew Dunstan │ 4
9fdb675fc5d │ Faster partition pruning │ Alvaro Herrera │ 4
1aba8e651ac │ Add hash partitioning. │ Robert Haas │ 4
6f6b99d1335 │ Allow a partitioned table to have a default partition. │ Robert Haas │ 4
eb7ed3f3063 │ Allow UNIQUE indexes on partitioned tables │ Alvaro Herrera │ 4
b96d550eb03 │ Support for optimizing and emitting code in LLVM JIT provider. │ Andres Freund │ 3
8224de4f42c │ Indexes with INCLUDE columns and their support in B-tree │ Teodor Sigaev │ 3
4b0d28de06b │ Remove secondary checkpoint │ Simon Riggs │ 3
9da0cc35284 │ Support parallel btree index builds. │ Robert Haas │ 2
1804284042e │ Add parallel-aware hash joins. │ Andres Freund │ 1

It's fair to say that anything in the list is scary regardless of score,
because:

1) Some respondents were vague and provided answers such as "Partition
improvements", which I attributed to several commits. In three cases
(all involving JIT) I added less commits than I probably should have,
but then there are so many of those commits that I'm not sure which are
relevant.

2) The mechanism to award points to each commit is quite unfair, but it
didn't seem important enough. We have too few answer anyhow :-(

Thanks to all respondents!

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Another way to look at it:

Alvaro = 6*2 + 4*4 = 28
Robert = 4*5 + 2 = 22
Andres = 5 + 3 + 1 = 9
Peter = 5
Andrew = 4
Teodor = 3
Simon = 3

A round of applause for our winner!

--
Fabien.

On 9 August 2018 at 04:32, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

499be013de6 │ Support partition pruning at execution time │ Alvaro Herrera │ 6

Perhaps adding the enable_partitition_pruning GUC was a good idea after all.

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

On Wed, Aug 8, 2018 at 5:59 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Another way to look at it:

Alvaro = 6*2 + 4*4 = 28
Robert = 4*5 + 2 = 22
Andres = 5 + 3 + 1 = 9
Peter = 5
Andrew = 4
Teodor = 3
Simon = 3

A round of applause for our winner!

Wow, apparently Alvaro and I are terrifying compared to everyone else. D'oh.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company