Bug #74427 crash when creating a table in a schema that was dropped and created again
Submitted: 17 Oct 2014 9:23 Modified: 2 Dec 2014 12:32
Reporter: Giuseppe Maxia (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: DDL Severity:S1 (Critical)
Version:5.7.5 labs OS:MacOS
Assigned to: CPU Architecture:Any
Tags: data dictionary

[17 Oct 2014 9:23] Giuseppe Maxia
Description:
Using the lab edition for data dictionary, do the following:

1) create a schema;
2) drop that schema
3) create that schema again
4) create a table in the new schema

mysql [localhost] {msandbox} ((none)) > create schema D1;
Query OK, 1 row affected (0.00 sec)

mysql [localhost] {msandbox} ((none)) > drop schema D1; create schema D1; create table D1.t1(i int);
Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

ERROR 2013 (HY000): Lost connection to MySQL server during query

How to repeat:
create schema D1;
drop schema D1; create schema D1; create table D1.t1(i int);
[18 Oct 2014 2:14] Giuseppe Maxia
Updated title to better describe the issue
[27 Oct 2014 7:55] MySQL Verification Team
Hello Giuseppe,

Thank you for the report and test case.
Confirmed the issue on Mac.

##
// mac os x mavericks, with Source Build able to reproduce the issue

mysql> show variables like '%version%';
+-------------------------+---------------------+
| Variable_name           | Value               |
+-------------------------+---------------------+
| innodb_version          | 5.7.5               |
| protocol_version        | 10                  |
| slave_type_conversions  |                     |
| version                 | 5.7.5-labs-dd       |
| version_comment         | Source distribution |
| version_compile_machine | x86_64              |
| version_compile_os      | osx10.9             |
+-------------------------+---------------------+
7 rows in set (0.00 sec)

mysql> create schema D1;
Query OK, 1 row affected (0.02 sec)

mysql> drop schema D1; create schema D1; create table D1.t1(i int);
Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.02 sec)

ERROR 2013 (HY000): Lost connection to MySQL server during query

// Could not repeat the issue with binary tarball on Linux

mysql> show variables like '%version%';
+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| innodb_version          | 5.7.5                        |
| protocol_version        | 10                           |
| slave_type_conversions  |                              |
| version                 | 5.7.5-labs-dd-log            |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | linux-el6                    |
+-------------------------+------------------------------+
7 rows in set (0.00 sec)

mysql> create schema D1;
Query OK, 1 row affected (0.00 sec)

mysql> drop schema D1; create schema D1; create table D1.t1(i int);
Query OK, 0 rows affected (0.01 sec)

Query OK, 1 row affected (0.00 sec)

Query OK, 0 rows affected (0.03 sec)

Thanks,
Umesh
[27 Oct 2014 11:37] MySQL Verification Team
// Source build on OL6 didn't crash

mysql> show variables like '%version%';
+-------------------------+---------------------+
| Variable_name           | Value               |
+-------------------------+---------------------+
| innodb_version          | 5.7.5               |
| protocol_version        | 10                  |
| slave_type_conversions  |                     |
| version                 | 5.7.5-labs-dd-log   |
| version_comment         | Source distribution |
| version_compile_machine | x86_64              |
| version_compile_os      | Linux               |
+-------------------------+---------------------+
7 rows in set (0.00 sec)

mysql> create schema D1;
Query OK, 1 row affected (0.00 sec)

mysql>  drop schema D1; create schema D1; create table D1.t1(i int);
Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.01 sec)

Query OK, 0 rows affected (0.02 sec)
[2 Dec 2014 12:32] Sivert Sørumgård
Thanks for the bug report. The issue has been fixed, but is not available externally yet.

Problems:
---------

1. The DD cache needs to re-generate cache name keys from dictionary objects to e.g. remove them. This code does not take l_c_t_n into account. The result is that in some cases (e.g. object removal), a dictionary object is deleted and the entry in the id cache is erased, while the entry in the name cache is kept, with a dangling pointer.

2. In the server code, calls into the DD module in some cases use the table alias, which for DDL operation is the table name with the case as submitted by the user. Instead, the table name must be used, which is the lowercase'd name when l_c_t_n == 2.

3. When a new table dictionary object is created, the table name with the case as submitted by the user must be stored persistently as the table name when l_c_t_n == 2.

Code changes:
-------------

1. Extend Object_table_definition_impl with two static methods:

i.  fs_name_collation() for returning the appropriate collation to use for file system related names. This method replaces case_insensitivity_collation_name(). Usage of the replaced method is updated accordingly.

ii. fs_name_case() for converting a file system related name to the correct case, depending on l_c_t_n.

Additionally, change the methods for generating object keys for the DD tables 'tables', 'schemata' and 'tablespaces' to use the 'fs_name_case()' method to generate the key with the appropriate case.

2. Change calls to dd_table_storage_engine() from the server to submit the table list instead of the table alias. Change the implementation of dd_table_storage_engine() to use the table_name member from the table list.

3. Change the setting of dd::Table::name to ensure the correct case is used for l_c_t_n == 2.