Bug#13982017: ALTER TABLE RENAME ENDS UP WITH ERROR 1050 (42S01)
Fixed by backport of: ------------------------------------------------------------ revno: 3402.50.156 committer: Jon Olav Hauglid <jon.hauglid@oracle.com> branch nick: mysql-trunk-test timestamp: Wed 2012-02-08 14:10:23 +0100 message: Bug#13417754 ASSERT IN ROW_DROP_DATABASE_FOR_MYSQL DURING DROP SCHEMA This assert could be triggered if an InnoDB table was being moved to a different database using ALTER TABLE ... RENAME, while this database concurrently was being dropped by DROP DATABASE. The reason for the problem was that no metadata lock was taken on the target database by ALTER TABLE ... RENAME. DROP DATABASE was therefore not blocked and could remove the database while ALTER TABLE ... RENAME was executing. This could cause the assert in InnoDB to be triggered. This patch fixes the problem by taking a IX metadata lock on the target database before ALTER TABLE ... RENAME starts moving a table to a different database. Note that this problem did not occur with RENAME TABLE which already takes the correct metadata locks. Also note that this patch slightly changes the behavior of ALTER TABLE ... RENAME. Before, the statement would abort and return an error if a lock on the target table name could not be taken immediately. With this patch, ALTER TABLE ... RENAME will instead block and wait until the lock can be taken (or until we get a lock timeout). This also means that it is possible to get ER_LOCK_DEADLOCK errors in this situation since we allow ALTER TABLE ... RENAME to wait and not just abort immediately.
Showing
Please register or sign in to comment