MDEV-37913: disable_index_merge_plans causes SELECT data loss when more than 100 ORs

*DRAFT*

SEL_TREE* tree_or(SEL_TREE *X, SEL_TREE *Y) tries to conserve memory.
In certain cases it reuses the X object for the return value.

MDEV-34620 has added logic to disable construction of index_merge plans
for multi-way ORs. That logic interfered with the logic above and has
caused an error like this:

for parameters of:

X = SEL_TREE{ trees=[key1_treeA, key2_treeB]}
Y = SEL_TREE{ trees=[key1_treeC ] }

we would decide to to reuse object X.
for key1, we would produce key_or(key1_treeA, key1_treeC)
but key2_treeB would be just left there.

As as result, for "X OR Y" we would a SEL_TREE with key2_treeB.
If one tries to construct index merge, that's essentially only reading
rows matching one of OR-parts of Y and missing rows matching X.

Fixed by clearing out trees like key2_treeB.

Author: spetrunia

mysql-test/main/range.result

@@ -3736,6 +3736,27 @@ DROP TABLE t1;
 #
 # End of 10.5 tests
 #
+#
+# MDEV-37913: disable_index_merge_plans causes SELECT data loss when more than 100 ORs
+#
+CREATE TABLE t1 (
+id int primary key,
+key1 int,
+index(key1)
+);
+INSERT INTO t1 VALUES
+(1, 1),
+(2, 1),
+(3, 2);
+$query;
+id	key1
+1	1
+2	1
+3	2
+drop table t1;
+#
+# End of 10.11 tests
+#
 set global innodb_stats_persistent= @innodb_stats_persistent_save;
 set global innodb_stats_persistent_sample_pages=
 @innodb_stats_persistent_sample_pages_save;

mysql-test/main/range.test

@@ -2533,6 +2533,32 @@ DROP TABLE t1;
 --echo # End of 10.5 tests
 --echo #
 
+--echo #
+--echo # MDEV-37913: disable_index_merge_plans causes SELECT data loss when more than 100 ORs
+--echo #
+CREATE TABLE t1 (
+  id int primary key,
+  key1 int,
+  index(key1)
+);
+
+INSERT INTO t1 VALUES
+(1, 1),
+(2, 1),
+(3, 2);
+
+let $query=`
+  select concat('select * from t1 where (key1 = 2 AND id = 3) ',
+               REPEAT(' OR (key1 = 1)', 100))
+`;
+
+evalp $query;
+
+drop table t1;
+
+--echo #
+--echo # End of 10.11 tests
+--echo #
 set global innodb_stats_persistent= @innodb_stats_persistent_save;
 set global innodb_stats_persistent_sample_pages=
               @innodb_stats_persistent_sample_pages_save;

mysql-test/main/range_mrr_icp.result

@@ -3725,6 +3725,27 @@ DROP TABLE t1;
 #
 # End of 10.5 tests
 #
+#
+# MDEV-37913: disable_index_merge_plans causes SELECT data loss when more than 100 ORs
+#
+CREATE TABLE t1 (
+id int primary key,
+key1 int,
+index(key1)
+);
+INSERT INTO t1 VALUES
+(1, 1),
+(2, 1),
+(3, 2);
+$query;
+id	key1
+1	1
+2	1
+3	2
+drop table t1;
+#
+# End of 10.11 tests
+#
 set global innodb_stats_persistent= @innodb_stats_persistent_save;
 set global innodb_stats_persistent_sample_pages=
 @innodb_stats_persistent_sample_pages_save;

sql/opt_range.cc

@@ -9979,6 +9979,20 @@ tree_or(RANGE_OPT_PARAM *param,SEL_TREE *tree1,SEL_TREE *tree2)
 
     if (no_imerge_from_ranges && no_merges1 && no_merges2)
     {
+      /*
+        If we have force-disabled index_merge, tree1 may have tree->keys[N] set
+        for some N which are not in the ored_keys bitmap.
+        Clear those out as they must not get into the result set.
+      */
+      if (param->disable_index_merge_plans)
+      {
+        key_map map1= tree1->keys_map;
+        map1.subtract(ored_keys);
+        key_map::Iterator it(map1);
+        int key_no;
+        while ((key_no= it++) != key_map::Iterator::BITMAP_END)
+          tree1->keys[key_no]= NULL;
+      }
       /*
         Reuse tree1 as the result in simple cases. This reduces memory usage
         for e.g. "key IN (c1, ..., cN)" which produces a lot of ranges.