]> granicus.if.org Git - postgresql/commit
Clean up side-effects of commits ab5fcf2b0 et al.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 7 Apr 2019 16:54:26 +0000 (12:54 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 7 Apr 2019 16:54:26 +0000 (12:54 -0400)
commit67999b3547f7ee8b8c099f41ddab3001e2792202
tree0b1d9004c4a3f2fd48feef0109ca5e7a052ebd61
parent7d18a55c90eb5a83c702c7cd8e23ae25c389a636
Clean up side-effects of commits ab5fcf2b0 et al.

Before those commits, partitioning-related code in the executor could
assume that ModifyTableState.resultRelInfo[] contains only leaf partitions.
However, now a fully-pruned update results in a dummy ModifyTable that
references the root partitioned table, and that breaks some stuff.

In v11, this led to an assertion or core dump in the tuple routing code.
Fix by disabling tuple routing, since we don't need that anyway.
(I chose to do that in HEAD as well for safety, even though the problem
doesn't manifest in HEAD as it stands.)

In v10, this confused ExecInitModifyTable's decision about whether it
needed to close the root table.  But we can get rid of that altogether
by being smarter about where to find the root table.

Note that since the referenced commits haven't shipped yet, this
isn't fixing any bug the field has seen.

Amit Langote, per a report from me

Discussion: https://postgr.es/m/20710.1554582479@sss.pgh.pa.us
src/backend/executor/nodeModifyTable.c
src/test/regress/expected/inherit.out
src/test/regress/sql/inherit.sql