On 24 July 2018 at 16:55, Jaime Casanova <jaime.casan...@2ndquadrant.com> wrote: > I was trying sqlsmith on REL_11_STABLE (commit > 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at > hand, and got an assertion failure. > It seems to happen during planning on prunning time but only when > tables get bigger than certain size. > > I configured it with "--enable-debug --enable-depend > --enable-cassert", attached is the backtrace and a script to reproduce > the problem.
It looks like an AppendPath which has a non-NIL partitioned_rels List won't always only contain leaf partitions as subpaths. The plan that the planner is trying to make here is: https://explain.depesz.com/s/26zj In this case, the 2nd to 5th Append subplan's parents are actually partitioned tables rather than leaf partitions. make_partition_pruneinfo() assumes these will always be leaf partitions. Looking more closely at accumulate_append_subpath() I can see that there are cases where it won't pull sub-Append paths into the main Append. That's what we're seeing in this plan. The fix is either to have make_partition_pruneinfo() return NIL to disable run-time pruning when any of the subpaths are not a leaf partition (it might be a good safety precaution regardless), or we could maybe think harder about what can be done in accumulate_append_subpath() to flatten the Append/MergeAppend paths in this case. I've attached a patch for the former. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
run-time_prune_tablesample_fix.patch
Description: Binary data
