]> granicus.if.org Git - postgresql/commit
Repair bogus EPQ plans generated for postgres_fdw foreign joins.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 12 Dec 2018 21:08:30 +0000 (16:08 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 12 Dec 2018 21:08:30 +0000 (16:08 -0500)
commit12cb7ea599fb651bddadcff5d55188cdc4633190
tree7638fa55bf408d16bea5b2b3fc19fc2445f74b9f
parent10bad8c0f02e43dd2448316c4658f50b75f9cba8
Repair bogus EPQ plans generated for postgres_fdw foreign joins.

postgres_fdw's postgresGetForeignPlan() assumes without checking that the
outer_plan it's given for a join relation must have a NestLoop, MergeJoin,
or HashJoin node at the top.  That's been wrong at least since commit
4bbf6edfb (which could cause insertion of a Sort node on top) and it seems
like a pretty unsafe thing to Just Assume even without that.

Through blind good fortune, this doesn't seem to have any worse
consequences today than strange EXPLAIN output, but it's clearly trouble
waiting to happen.

To fix, test the node type explicitly before touching Join-specific
fields, and avoid jamming the new tlist into a node type that can't
do projection.  Export a new support function from createplan.c
to avoid building low-level knowledge about the latter into FDWs.

Back-patch to 9.6 where the faulty coding was added.  Note that the
associated regression test cases don't show any changes before v11,
apparently because the tests back-patched with 4bbf6edfb don't actually
exercise the problem case before then (there's no top-level Sort
in those plans).

Discussion: https://postgr.es/m/8946.1544644803@sss.pgh.pa.us
contrib/postgres_fdw/postgres_fdw.c
src/backend/optimizer/plan/createplan.c
src/include/optimizer/planmain.h