Bug#40972: some sql execution lead the whole databse crashing

Problem was an errornous date that lead to end partition
was before the start, leading to a crash.

Solution was to check greater or equal instead of only
equal between start and end partition.

NOTE: partitioning pruning handles incorrect dates
differently than index lookup, which can give different
results in a partitioned table versus a non partitioned
table for queries having 'bad' dates in the where clause.

mysql-test/r/partition_pruning.result:
  Bug#40972: some sql execution lead the whole databse crashing
  
  Updated result file
mysql-test/t/partition_pruning.test:
  Bug#40972: some sql execution lead the whole databse crashing
  
  Added test.
sql/sql_partition.cc:
  Bug#40972: some sql execution lead the whole databse crashing
  
  There can be cases where the start/cur partition is greater
  than the end partition, so it must not continue, since that
  can lead to a crash.

1 files changed, 2 insertions, 2 deletions

diff --git a/sql/sql_partition.cc b/sql/sql_partition.cc
index c1df5552eb9..9096a2b91ef 100644
--- a/sql/sql_partition.cc
+++ b/sql/sql_partition.cc
@@ -6760,7 +6760,7 @@ int get_part_iter_for_interval_via_mapping(partition_info *part_info,
     store_key_image_to_rec(field, max_value, field_len);
     bool include_endp= !test(flags & NEAR_MAX);
     part_iter->part_nums.end= get_endpoint(part_info, 0, include_endp);
-    if (part_iter->part_nums.start == part_iter->part_nums.end &&
+    if (part_iter->part_nums.start >= part_iter->part_nums.end &&
         !part_iter->ret_null_part)
       return 0; /* No partitions */
   }
@@ -6938,7 +6938,7 @@ int get_part_iter_for_interval_via_walking(partition_info *part_info,
 
 uint32 get_next_partition_id_range(PARTITION_ITERATOR* part_iter)
 {
-  if (part_iter->part_nums.cur == part_iter->part_nums.end)
+  if (part_iter->part_nums.cur >= part_iter->part_nums.end)
   {
     part_iter->part_nums.cur= part_iter->part_nums.start;
     return NOT_A_PARTITION_ID;