Fix for bug #58650 "Failing assertion: primary_key_no == -1 ||

primary_key_no == 0".

Attempt to create InnoDB table with non-nullable column of
geometry type having an unique key with length 12 on it and
with some other candidate key led to server crash due to
assertion failure in both non-debug and debug builds.

The problem was that such a non-candidate key could have
been sorted as the first key in table/.FRM, before any legit
candidate keys. This resulted in assertion failure in InnoDB
engine which assumes that primary key should either be the
first key in table/.FRM or should not exist at all.

The reason behind such an incorrect sorting was an wrong
value of Create_field::key_length member for geometry field
(which was set to its pack_length == 12) which confused code
in mysql_prepare_create_table(), so it would skip marking
such key as a key with partial segments.

This patch fixes the problem by ensuring that this member
gets the same value of Create_field::key_length member as 
for other blob fields (from which geometry field class is
inherited), and as result unique keys on geometry fields
are correctly marked as having partial segments.


mysql-test/include/gis_keys.inc:
  Added test case for bug #58650 "Failing assertion:
  primary_key_no == -1 || primary_key_no == 0".
mysql-test/r/gis.result:
  Added test case for bug #58650 "Failing assertion:
  primary_key_no == -1 || primary_key_no == 0".
mysql-test/suite/innodb/r/innodb_gis.result:
  Added test case for bug #58650 "Failing assertion:
  primary_key_no == -1 || primary_key_no == 0".
mysql-test/suite/innodb_plugin/r/innodb_gis.result:
  Added test case for bug #58650 "Failing assertion:
  primary_key_no == -1 || primary_key_no == 0".
sql/field.cc:
  Changed Create_field::create_length_to_internal_length() to
  correctly set Create_field::key_length member for geometry
  fields. Similar to the blob types key_length for such fields
  should be the same as length and not field's packed length
  (which is always 12 for geometry).
  
  As result of this change code handling table creation now
  always correctly identifies btree/unique keys on geometry
  fields as partial keys, so such keys can't be erroneously
  treated as candidate keys and sorted in keys array in .FRM
  before legit candidate keys.
  
  This fixes bug #58650 "Failing assertion: primary_key_no ==
  -1 || primary_key_no == 0" in which incorrect candidate key
  sorting led to assertion failure in InnoDB code.

1 files changed, 12 insertions, 0 deletions

diff --git a/mysql-test/suite/innodb/r/innodb_gis.result b/mysql-test/suite/innodb/r/innodb_gis.result
index c6c775afc9f..a52a1387b6e 100644
--- a/mysql-test/suite/innodb/r/innodb_gis.result
+++ b/mysql-test/suite/innodb/r/innodb_gis.result
@@ -585,5 +585,17 @@ COUNT(*)
 2
 DROP TABLE t1, t2;
 End of 5.0 tests
+#
+# Test for bug #58650 "Failing assertion: primary_key_no == -1 ||
+#                      primary_key_no == 0".
+#
+drop table if exists t1;
+# The minimal test case.
+create table t1 (a int not null, b linestring not null, unique key b (b(12)), unique key a (a));
+drop table t1;
+# The original test case.
+create table t1 (a int not null, b linestring not null, unique key b (b(12)));
+create unique index a on t1(a);
+drop table t1;
 create table t1 (g geometry not null, spatial gk(g)) engine=innodb;
 ERROR HY000: The used table type doesn't support SPATIAL indexes