Fix EPQ run-time pruning using the parent's PARAM_EXEC values 8741e48e5 made EvalPlanQualStart() borrow the parent EState's es_part_prune_states. However, the ExprContext in each PartitionPruneState belongs to the parent EState, so exec pruning during an EPQ recheck used the parent's PARAM_EXEC values, i.e. those from the old row version. This could prune away the partition the recheck needed, causing the row to be silently skipped, e.g. with a correlated subquery on a partitioned table in the WHERE clause of an UPDATE.
Here we fix this by giving the EPQ EState its own PartitionPruneStates, while still borrowing the parent's es_part_prune_results so that the same subplans are initialized. As the states are no longer shared, the "initialized" field added by 1b5dd3a24 is no longer needed, so remove it. This also undoes the ABI break that field caused in 18. Backpatch to 18, where 8741e48e5 and 1b5dd3a24 were backpatched. Author: Zsolt Parragi <[email protected]> Reviewed-by: David Rowley <[email protected]> Discussion: https://postgr.es/m/CAN4CZFPZ6qKnv6FPmq1RQZ49cHALCwLBu_NJdqUrkZNg0z81JQ%40mail.gmail.com Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/57193b3a09ed3555e9c6e3822173427a3249b335 Modified Files -------------- src/backend/executor/execMain.c | 7 +++- src/backend/executor/execPartition.c | 42 +++++++++++++++------- src/include/executor/execPartition.h | 4 +-- .../expected/eval-plan-qual-partition-prune.out | 16 +++++++++ .../specs/eval-plan-qual-partition-prune.spec | 13 ++++++- 5 files changed, 65 insertions(+), 17 deletions(-)
