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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/73e69062c120f669f71531dabeacfb8041c85daf 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(-)
