Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results.
The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <[email protected]> Diagnosed-by: Jacob Brazeal <[email protected]> Author: David Rowley <[email protected]> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=z79mtah6xun1v4pekxlvcnv8mxs8wn...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9a0cd8e73f52307162f0c81e2d6e52c79f5592c3 Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-)
