Further fix for EvalPlanQual with mix of local and foreign partitions.
authorEtsuro Fujita <efujita@postgresql.org>
Thu, 3 Feb 2022 06:15:01 +0000 (15:15 +0900)
committerEtsuro Fujita <efujita@postgresql.org>
Thu, 3 Feb 2022 06:15:01 +0000 (15:15 +0900)
commit7b0cec2fa05a123ed96163d7ac8485384570b3e0
tree39f37179388288d25d853f67593e01f78791bccb
parent25560761289e5dbe21514c9ef2cf7272d9181488
Further fix for EvalPlanQual with mix of local and foreign partitions.

We assume that direct-modify ForeignScan nodes cannot be re-evaluated
during EvalPlanQual processing, but the rework for inherited
UPDATE/DELETE in commit 86dc90056 changed things, without considering
that, so that such ForeignScan nodes get called as part of the
EvalPlanQual subtree during EvalPlanQual processing in the case of an
inherited UPDATE/DELETE where the inheritance set contains foreign
target relations.  To avoid re-evaluating such ForeignScan nodes during
EvalPlanQual processing, commit c3928b467 modified nodeForeignscan.c,
but the assumption made there that ExecForeignScan() should never be
called for such ForeignScan nodes during EvalPlanQual processing turned
out to be wrong in some cases, leading to a segmentation fault or a
"cannot re-evaluate a Foreign Update or Delete during EvalPlanQual"
error.

Fix by modifying nodeForeignscan.c further to avoid re-evaluating such
ForeignScan nodes even in ExecForeignScan()/ExecReScanForeignScan()
during EvalPlanQual processing.  Since this makes non-reachable the
test-and-elog added to ForeignNext() by commit c3928b467 that produced
the aforesaid error, convert the test-and-elog to an Assert.

Per bug #17355 from Alexander Lakhin.  Back-patch to v14 where both
commits came in.

Patch by me, reviewed and tested by Alexander Lakhin and Amit Langote.

Discussion: https://postgr.es/m/17355-de8e362eb7001a96@postgresql.org
src/backend/executor/nodeForeignscan.c