| Bug #46273 | New MDL: Bug#989 is not fully fixed in case of ALTER. | ||
|---|---|---|---|
| Submitted: | 17 Jul 2009 18:03 | Modified: | 7 Mar 2010 2:06 |
| Reporter: | Konstantin Osipov (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | 6.0-codebase | OS: | Any |
| Assigned to: | Dmitry Lenev | CPU Architecture: | Any |
[17 Jul 2009 19:02]
MySQL Verification Team
Kostja, Isn't this bug a duplicate of #37346 ??? Please, check it out !!!
[18 Jul 2009 13:51]
Valeriy Kravchuk
Thank you for the bug report. Verified just as described with recent 5.4.4 from bzr
[20 Jul 2009 7:29]
Konstantin Osipov
It is not a duplicate, the bug you mention is an effect of multiple issues. I'm breaking each of them down into individual bugs.
[22 Oct 2009 10:17]
Dmitry Lenev
Hello! I have commited the patch which should fix this bug among the other issues: http://lists.mysql.com/commits/87077 3626 Dmitry Lenev 2009-10-16 Implementation of simple deadlock detection for metadata locks. This change is supposed to reduce number of ER_LOCK_DEADLOCK errors which occur when multi-statement transaction encounters conflicting metadata lock in cases when waiting is possible. ... This patch also fixes bug #46273 "MySQL 5.4.4 new MDL: Bug#989 is not fully fixed in case of ALTER". ...
[29 Dec 2009 13:12]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/95789 3718 Konstantin Osipov 2009-12-29 Bug#46273, commit to be able to backport.
[30 Dec 2009 18:10]
Dmitry Lenev
Fix for this bug was queued into mysql-next-4248 tree as: http://lists.mysql.com/commits/95820 3047 Dmitry Lenev 2009-12-30 Implementation of simple deadlock detection for metadata locks. This change is supposed to reduce number of ER_LOCK_DEADLOCK errors which occur when multi-statement transaction encounters conflicting metadata lock in cases when waiting is possible.
[12 Jan 2010 18:28]
Konstantin Osipov
Queued in next-4284 (5.5-m3)
[16 Feb 2010 16:45]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100216101445-2ofzkh48aq2e0e8o) (version source revid:dlenev@mysql.com-20091231081605-n5epraxs9xaygw1v) (merge vers: 6.0.14-alpha) (pib:16)
[16 Feb 2010 16:55]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100216101208-33qkfwdr0tep3pf2) (version source revid:dlenev@mysql.com-20091230175330-6j79cxegheg1vusg) (pib:16)
[2 Mar 2010 0:59]
Paul DuBois
Not present in any released version. No changelog entry needed. Setting report to Need Merge pending push of Celosia into release tree.
[6 Mar 2010 11:00]
Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:vvaintroub@mysql.com-20100216221947-luyhph0txl2c5tc8) (merge vers: 5.5.99-m3) (pib:16)
[6 Mar 2010 23:56]
Paul DuBois
No changelog entry needed.
Description: ALTER TABLE is sometimes allowed to proceed even when a table is used by some other transaction, if concurrency is right. This is storage engine agnostic. Please see the test case below for details. How to repeat: Add a debug sync point to copy_data_between_tables() function, used by mysql_alter_table(): === modified file 'sql/sql_table.cc' --- sql/sql_table.cc 2009-07-10 12:31:32 +0000 +++ sql/sql_table.cc 2009-07-17 15:59:59 +0000 @@ -7794,6 +7794,7 @@ copy_data_between_tables(TABLE *from,TAB Create_field *def; DBUG_ENTER("copy_data_between_tables"); + DEBUG_SYNC(thd, "copy_data_between_tables"); /* Turn off recovery logging since rollback of an alter table is to delete the new table so there is no need to log the changes to it. Use the following test case: --source include/have_debug_sync.inc --disable_warnings drop table if exists t1; --enable_warnings connect (con1,localhost,root,,test,,); connection default; create table t1 (c1 int primary key, c2 int, c3 int) engine=myisam; insert into t1 values (1,1,0),(2,2,0),(3,3,0),(4,4,0),(5,5,0); set autocommit=0; begin; update t1 set c3=c3+1 where c2=3; connection con1; set debug_sync='copy_data_between_tables SIGNAL copy_data_reached WAIT_FOR alter_go'; send alter table t1 add column e int, rename to t2; connection default; set debug_sync='now wait_for copy_data_reached'; set debug_sync='wait_for_lock SIGNAL alter_go'; send update t1 set c3=c3+1 where c2=4; connection con1; reap; connection default; --error ER_NO_SUCH_TABLE reap; set debug_sync="reset"; disconnect con1; drop table t2; It produces the following result: drop table if exists t1; create table t1 (c1 int primary key, c2 int, c3 int) engine=myisam; insert into t1 values (1,1,0),(2,2,0),(3,3,0),(4,4,0),(5,5,0); set autocommit=0; begin; update t1 set c3=c3+1 where c2=3; set debug_sync='copy_data_between_tables SIGNAL copy_data_reached WAIT_FOR alter_go'; alter table t1 add column e int, rename to t2; set debug_sync='now wait_for copy_data_reached'; set debug_sync='wait_for_lock SIGNAL alter_go'; update t1 set c3=c3+1 where c2=4; ERROR 42S02: Table 'test.t1' doesn't exist set debug_sync="reset"; drop table t2; Observe "table doesn't exist" error. It shouldn't happen! Suggested fix: Please make sure the test case is still relevant after Bug#46272 is fixed. Once it's fixed, one might need a different test case to reproduce the problem (since the abortion will happen in notify_thread_having_shared_lock(), rather than in mysql_abort_locks()).