Bug #12347 InnoDB: DROP TABLE ignores locks
Submitted: 3 Aug 2005 14:42 Modified: 1 Dec 2008 19:59
Reporter: Peter Gulutzan Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: DDL Severity:S3 (Non-critical)
Version:5.0.11-beta-debug OS:Linux (SUSE 9.2)
Assigned to: Assigned Account CPU Architecture:Any

[3 Aug 2005 14:42] Peter Gulutzan
Description:
I have an InnoDB table.
I say "select from table for update" on connection #1.
I say "delete from table" on connection #2. It is blocked. Good.
I say "drop table" on connection #2. It is not blocked. Bad.

Since a DROP implicitly deletes all rows, anything that
blocks a DELETE should block a DROP.

See also bug#989: InnoDB: if DROP TABLE while there's an
active transaction, wrong binlog order.

How to repeat:
On connection #1, say:

create table tino (s1 int) engine=innodb;
insert into tino values (1);
commit;
start transaction;
select * from tino for update;

On connection #2, say:
drop table tino;
[3 Aug 2005 14:48] Heikki Tuuri
Peter G,

the current behavior was a conscious decision in December 2000. Waiting for a transactional lock while holding the MySQL table cache mutex would freeze the whole server.

To fix that bad binlog order bug we may need to let DROP TABLE to wait for a transactional lock. I agree that it would be more logical that a lock would protect a table against being dropped.

Regards,

Heikki
[3 Aug 2005 14:57] Heikki Tuuri
Putting this to 'To be fixed later' state. We will not fix this in 5.0.
--Heikki
[27 Sep 2008 12:54] Konstantin Osipov
Duplicate of Bug#989. Davi, please check if can be closed as such when Bug#989 is closed. Please consider adding a test case.
[29 Sep 2008 22:33] Konstantin Osipov
Another manifestation of Bug#989.