• davi@endora.local's avatar
    Bug#31397 Inconsistent drop table behavior of handler tables. · 94e6e4ff
    davi@endora.local authored
    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.
    94e6e4ff
sql_class.cc 93.8 KB