Fix assorted partition pruning bugs
Alvaro Herrera <alvherre@alvh.no-ip.org>
Fix assorted partition pruning bugs match_clause_to_partition_key failed to consider COERCION_PATH_ARRAYCOERCE cases in scalar-op-array expressions, so it was possible to crash the server easily. To handle this case properly (ie. prune partitions) we would need to run a bit of executor code during planning. Maybe it can be improved, but for now let's just not crash. Add a test case that used to trigger the crash. Author: Michaël Paquier match_clause_to_partition_key failed to indicate that operators that don't have a commutator in a btree opclass are unsupported. It is possible for this to cause a crash later if such an operator is used in a scalar-op-array expression. Add a test case that used to the crash. Author: Amit Langote One caller of gen_partprune_steps_internal in match_clause_to_partition_key was too optimistic about the former never returning an empty step list. Rid it of its innocence. (Having fixed the bug above, I no longer know how to exploit this, so no test case for it, but it remained a bug.) Revise code flow a little bit, for succintness. Author: Álvaro Herrera Reported-by: Marina Polyakova Reviewed-by: Michaël Paquier Reviewed-by: Amit Langote Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/ff8f9bfa485ff961d6bb43e54120485b@postgrespro.ru
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/partitioning/partprune.c | modified | +26 −32 |
| src/test/regress/expected/partition_prune.out | modified | +66 −0 |
| src/test/regress/sql/partition_prune.sql | modified | +14 −0 |
Discussion
- path toward faster partition pruning 403 messages · 2017-08-21 → 2018-05-10