bzr push into mysql-trunk branch (Dmitry.Lenev:3958 to 3959) Bug#11747177

[Dmitry Lenev]

 3959 Dmitry Lenev	2012-06-07
      Added test case for bug #11747177 - '31149: "SPECIFIED KEY
      WAS TOO LONG" IS PRINTED THREE TIMES.'.
      
      This bug was fixed by changes which were done for WL#5534
      "Online ALTER, Phase 1".

    modified:
      internal/mysql-test/suite/i_main/r/alter_table.result
      internal/mysql-test/suite/i_main/t/alter_table.test
 3958 Jorgen Loland	2012-06-07
      Bug#11765737: USE_COUNT: WRONG COUNT FOR KEY AT 0X7FFFD423EDE0,
                    0 SHOULD BE 1
      
      SEL_ARG::use_count is used to keep track of the number of 
      times a SEL_ARG is referred. SEL_ARGs are e.g. referred
      from SEL_ARGs with an earlier key part number. This is done so 
      that multiple range predicates with equal subparts can use the
      same SEL_ARG instead of duplicating the effort. If an index is
      created with two keyparts (kp1, kp2) and the query contains the
      predicate "(kp1=1 or kp1=2) and (kp2>3)", two SEL_ARGs needs
      to be created for the kp1 part of the predicate. Both these 
      SEL_ARGs will have use_count=1. Furthermore, both will point 
      to the SEL_ARG for kp2 which will have use_count=2.
      
      The bug was in SEL_ARG::increment_use_count() which is called
      on a SEL_ARG when more SEL_ARGs start referring to it. When
      increment_use_count() was called on a SEL_ARG, the SEL_ARGs
      it referred to was incremented by the input increment multiplied
      by the SEL_ARGs previous use_count. For a predicate
      "(kp1=1 or kp1=2 or kp1=3) and (kp2>3) and kp3>4" that means 
      that when these SEL_ARG trees get merged (use count numbers in
      brackets):
      "(kp1=1[1] or kp1=2[1]) and kp2>3[2] and kp3>4[2]" 
      "kp1=3[1]               and kp2>3[1] and kp3>4[1]",
      increment_use_count() would add 1 to use_count of kp2 and 2 to 
      use_count of kp3, resulting in this SEL_ARG tree:
      "(kp1=1[1] or kp1=2[1] or kp1=2[1]) and kp2>3[3] and kp3>4[4]"
      
      The use_count of kp3 should have been 3. The fix is to remove
      the multiplication of use_count in 
      SEL_ARG::increment_use_count().

    modified:
      internal/mysql-test/suite/i_main/r/range.result
      internal/mysql-test/suite/i_main/t/range.test
      sql/opt_range.cc
=== modified file 'internal/mysql-test/suite/i_main/r/alter_table.result'
--- a/internal/mysql-test/suite/i_main/r/alter_table.result	2012-06-07 03:42:57 +0000
+++ b/internal/mysql-test/suite/i_main/r/alter_table.result	2012-06-07 08:31:28 +0000
@@ -16,3 +16,13 @@ FOREIGN KEY(field1) REFERENCES
 table_13840553(ANY_FIELD)) ENGINE=INNODB;
 ERROR HY000: Cannot add foreign key constraint
 DROP TABLE table_13840553, table_13840553_1;
+#
+# Bug #11747177 - 31149: "SPECIFIED KEY WAS TOO LONG" IS PRINTED
+#                 THREE TIMES.
+#
+CREATE TABLE t1 (a varchar(30000)) ENGINE=MyISAM;
+# The statement below should emit warning only once, and not more times.
+CREATE INDEX i1 ON t1 (a);
+Warnings:
+Warning	1071	Specified key was too long; max key length is 1000 bytes
+DROP TABLE t1;

=== modified file 'internal/mysql-test/suite/i_main/t/alter_table.test'
--- a/internal/mysql-test/suite/i_main/t/alter_table.test	2012-06-07 03:42:57 +0000
+++ b/internal/mysql-test/suite/i_main/t/alter_table.test	2012-06-07 08:31:28 +0000
@@ -21,3 +21,13 @@ CREATE TABLE table_13840553_2 (field1 IN
                                FOREIGN KEY(field1) REFERENCES
                                table_13840553(ANY_FIELD)) ENGINE=INNODB;
 DROP TABLE table_13840553, table_13840553_1;
+
+
+--echo #
+--echo # Bug #11747177 - 31149: "SPECIFIED KEY WAS TOO LONG" IS PRINTED
+--echo #                 THREE TIMES.
+--echo #
+CREATE TABLE t1 (a varchar(30000)) ENGINE=MyISAM;
+--echo # The statement below should emit warning only once, and not more times.
+CREATE INDEX i1 ON t1 (a);
+DROP TABLE t1;

No bundle (reason: useless for push emails).