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, 12 insertions, 0 deletions

diff --git a/mysql-test/r/partition_pruning.result b/mysql-test/r/partition_pruning.result
index b153ad9ad47..26ddc92e97b 100644
--- a/mysql-test/r/partition_pruning.result
+++ b/mysql-test/r/partition_pruning.result
@@ -1,4 +1,16 @@
 drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
+CREATE TABLE t1
+(a INT NOT NULL AUTO_INCREMENT,
+b DATETIME,
+PRIMARY KEY (a,b),
+KEY (b))
+PARTITION BY RANGE (to_days(b))
+(PARTITION p0 VALUES LESS THAN (733681) COMMENT = 'LESS THAN 2008-10-01',
+PARTITION p1 VALUES LESS THAN (733712) COMMENT = 'LESS THAN 2008-11-01',
+PARTITION pX VALUES LESS THAN MAXVALUE);
+SELECT a,b FROM t1 WHERE b >= '2008-12-01' AND b < '2009-12-00';
+a	b
+DROP TABLE t1;
 create table t1 ( a int not null) partition by hash(a) partitions 2;
 insert into t1 values (1),(2),(3);
 explain select * from t1 where a=5 and a=6;