Bug#25164 create table `a` as select * from `A` hangs
The problem from a user's perspective: user creates table A, and then tries to CREATE TABLE a SELECT from A - and this causes a deadlock error, a hang, or fails with a debug assert, but only if the storage engine is InnoDB. The origin of the problem: InnoDB uses case-insensitive collation (system_charset_info) when looking up the internal table share, thus returning the same share for 'a' and 'A'. Cause of the user-visible behavior: since the same share is returned to SQL locking subsystem, it assumes that the same table is first locked (within the same session) for WRITE, and then for READ, and returns a deadlock error. However, the code is wrong in not properly cleaning up upon an error, leaving external locks in place, which leads to assertion failures and hangs. Fix that has been implemented: the SQL layer should properly propagate the deadlock error, cleaning up and freeing all resources. Further work towards a more complete solution: InnoDB should not use case insensitive collation for table share hash if table names on disk honor the case. mysql-test/r/innodb-deadlock.result: Bug#25164 test case result mysql-test/t/innodb-deadlock.test: Bug#25164 test case. The CREATE TABLE may fail depending on the character set of the system and filesystem, but it should never hang. sql/lock.cc: Unlock the storage engine "external" table level locks, if the MySQL thr_lock locking subsystem detects a deadlock error.
Showing
Please register or sign in to comment