I wrote:
> OK, so here's a finished set of patches for this issue.
> 0001 is the same patch I posted on Tuesday; I kept it separate just
> because it seemed like a largely separable set of changes. (Note that
> the undesirable regression test output changes are undone by 0002.)
> 0002 implements the map-vars-back-to-the-inheritance parent change
> per my sketch. Notice that relation aliases and Var names change
> underneath Appends/MergeAppends, but Vars above one are (mostly)
> printed the same as before. On the whole I think this is a good
> set of test output changes, reflecting a more predictable approach
> to assigning aliases to inheritance children. But somebody else
> might see it differently I suppose.
> Finally, 0003 is the remaining portion of David's patch to allow
> deletion of all of an Append/MergeAppend's sub-plans during
> executor startup pruning.
I pushed these, and the buildfarm immediately got a bad case of
the measles. All the members using force_parallel_mode = regress
fail on the new regression test case added by 0003, with diffs
like this:
diff -U3
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/partition_prune.out
---
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out
Thu Dec 12 00:40:04 2019
+++
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/partition_prune.out
Thu Dec 12 00:45:44 2019
@@ -3169,10 +3169,12 @@
--------------------------------------------
Limit (actual rows=0 loops=1)
Output: ma_test.a, ma_test.b
+ Worker 0: actual rows=0 loops=1
-> Merge Append (actual rows=0 loops=1)
Sort Key: ma_test.b
+ Worker 0: actual rows=0 loops=1
Subplans Removed: 3
-(5 rows)
+(7 rows)
deallocate mt_q2;
reset plan_cache_mode;
This looks to me like there's some other part of EXPLAIN that
needs to be updated for the possibility of zero child nodes, but
I didn't find out just where in a few minutes of searching.
As a stopgap to get back to green buildfarm, I removed this
specific test case, but we need to look at it closer.
regards, tom lane
