MySQL Bugs: #12347: InnoDB: DROP TABLE ignores locks

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

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;

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

Putting this to 'To be fixed later' state. We will not fix this in 5.0.
--Heikki

Duplicate of Bug#989. Davi, please check if can be closed as such when Bug#989 is closed. Please consider adding a test case.

Another manifestation of Bug#989.