Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as:
p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <[email protected]> Reviewed-by: Tender Wang <[email protected]> Reviewed-by: David Rowley <[email protected]> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zwkybnwp0auvefnai2ez2voywrhxb6h...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1d8a9333693a2b8a4851bc33324fbc4873b72cd3 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-)
