MySQL Bugs: #31397: Inconsistent drop table behavior of handler tables.

Bug #31397	Inconsistent drop table behavior of handler tables.
Submitted:	4 Oct 2007 13:23	Modified:	18 Dec 2007 21:30
Reporter:	Davi Arnaut (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.2 BK	OS:	Any
Assigned to:	Davi Arnaut	CPU Architecture:	Any
Tags:	Drop, flush tables, handler

Description:
Handlers whose tables are marked for reopen are not being properly dropped
after the table that they are associated to is dropped.

How to repeat:
#
# Flush tables and drop table which has an associated handler
#

--disable_warnings
drop table if exists t1;
--enable_warnings
create table t1 (a int);
handler t1 open as t1_alias;
flush tables;
drop table t1;
create table t1 (a int);
handler t1 open as t1_alias;
handler t1_alias close;

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/38156

ChangeSet@1.2615, 2007-11-20 15:17:53-02:00, davi@endora.local +9 -0
  Bug#31397 Inconsistent drop table behavior of handler tables.
  
  The problem is that DROP TABLE and other DDL statements failed to
  automatically close handlers associated with tables that were marked
  for reopen (FLUSH TABLES).
  
  The current implementation fails to properly discard handlers of
  dropped tables (that were marked for reopen) because it searches
  on the open handler tables list and using the current alias of the
  table being dropped. The problem is that it must not use the open
  handler tables list to search because the table might have been
  closed (marked for reopen) by a flush tables command and also it
  must not use the current table alias at all since multiple different
  aliases may be associated with a single table. This is specially
  visible when a user has two open handlers (using alias) of a same
  table and a flush tables command is issued before the table is
  dropped (see test case). Scanning the handler table list is also
  useless for dropping handlers associated with temporary tables,
  because temporary tables are not kept in the THD::handler_tables
  list.
  
  The solution is to simple scan the handlers hash table searching
  for, and deleting all handlers with matching table names if the
  reopen flag is not passed to the flush function, indicating that
  the handlers should be deleted. All matching handlers are deleted
  even if the associated the table is not open.

Pushed into 5.1.23-rc

Pushed into 6.0.5-alpha

Noted in 5.1.23, 6.0.5 changelogs.

For a table that had been opened with HANDLER and marked for
reopening after being closed with FLUSH TABLES, DROP TABLE did not
properly discard the handler.