Bug #37189 can't drop table during an uncommited transaction
Submitted: 4 Jun 2008 10:44 Modified: 4 Jun 2008 14:06
Reporter: Susanne Ebrecht Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:6.0.6 OS:Any
Assigned to: CPU Architecture:Any

[4 Jun 2008 10:44] Susanne Ebrecht
mysql> select version();

Build from bzr tree of last night.

create table t1(id serial) engine=falcon;
insert into t1 values();

insert into t1 values();

drop table t1;
ERROR 1051 (42S02): Unknown table 't1'

Only after commit/rollback of THREAD 2 you can drop the table by using THREAD 1. 

Also the error message is confusing.
If its one of FALCON specialities that you can't drop the table during waiting of an open transaction, then the error message should be something more senseful like: "you can't drop the table because of an open transaction"·

Testing with InnoDB:
You can drop the table anyway. Doesn't matter if there is another transaction waiting for commit/rollback or not.

How to repeat:
See above

Suggested fix:
The minimum of fixing is to change the error message.
[4 Jun 2008 11:21] Vladislav Vaintroub
Hi Susanne, 
why do you think this is not a duplicate of Bug#33258?
There, the complain is confusing error message as well (Bug#33258 - Misleading Error when DROP TABLE operation while a transaction is open)
Note, that Falcon does provide all necessary information about the cause of failing DROP to the server. The server just ignores it, unfortunately

Note also, you should be able to see more in "show warnings".

drop table t1;
ERROR 42S02: Unknown table 't1'
show warnings;
Level   Code    Message
Error   177     Can't execute the given command because you have active locked tables or an active transaction
[4 Jun 2008 13:55] Hakan Küçükyılmaz
Susanne, this is expected behavior. However, the error message is quite confusing.
[4 Jun 2008 14:06] Ann Harrison
This is a duplicate of 33258, which also complains first that you
can't drop a table that is in use by a different transaction and
second, that the server returns an incomprehensible error message.

The first behavior is correct, as described in bug 33258, with the
following caveat, also mentioned there.  In Falcon, dropping a table
is not equivalent to deleting all rows in a table.  Deleting rows
leaves behind old versions of the deleted records that preserve
the consistent snapshot available to running transactions.  DROP
is a metadata operation, after a DROP, the table is completely gone,
including all back versions, etc.