]> granicus.if.org Git - postgresql/commit
Fix assorted partition pruning bugs
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 9 May 2018 13:51:23 +0000 (10:51 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 9 May 2018 14:27:04 +0000 (11:27 -0300)
commitd758d9702e2f64f08565e18eb6cb7991efa2dc16
tree47f653a0c08c060fd7efb32d2850b88920597eb2
parent35361ee78890ce5b559a710c8fa2fdfa843eb280
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
src/backend/partitioning/partprune.c
src/test/regress/expected/partition_prune.out
src/test/regress/sql/partition_prune.sql