Revise make_partition_pruneinfo to not use its partitioned_rels input.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 1 Feb 2021 19:05:51 +0000 (14:05 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 1 Feb 2021 19:05:51 +0000 (14:05 -0500)
commitfb2d645dd53ff571572d830e830fc8c368063802
tree4a5bfccc4f43a52b370767f0e08351dae4d503ed
parent3696a600e2292d43c00949ddf0352e4ebb487e5b
Revise make_partition_pruneinfo to not use its partitioned_rels input.

It turns out that the calculation of [Merge]AppendPath.partitioned_rels
in allpaths.c is faulty and sometimes omits relevant non-leaf partitions,
allowing an assertion added by commit a929e17e5a8 to trigger.  Rather
than fix that, it seems better to get rid of those fields altogether.
We don't really need the info until create_plan time, and calculating
it once for the selected plan should be cheaper than calculating it
for each append path we consider.

As a first step, teach make_partition_pruneinfo to collect the relevant
partitioned tables for itself.  It's not hard to do so by traversing
from child tables up to parents using the AppendRelInfo links.

While here, make some minor stylistic improvements; mainly, don't use
the "Relids" alias for bitmapsets that are not identities of any
relation considered by the planner.  Try to document the logic better,
too.

No backpatch, as there does not seem to be a live problem before
a929e17e5a8.  Also no new regression test; the code where the bug
was will be gone at the end of this patch series, so it seems a
bit pointless to memorialize the issue.

Tom Lane and David Rowley, per reports from Andreas Seltenreich
and Jaime Casanova.

Discussion: https://postgr.es/m/87sg8tqhsl.fsf@aurora.ydns.eu
Discussion: https://postgr.es/m/CAJKUy5gCXDSmFs2c=R+VGgn7FiYcLCsEFEuDNNLGfoha=pBE_g@mail.gmail.com
src/backend/partitioning/partprune.c