• istruewing@stella.local's avatar
    Bug#30273 - merge tables: Can't lock file (errno: 155) · 55aa6376
    istruewing@stella.local authored
    The patch for Bug 26379 (Combination of FLUSH TABLE and
    REPAIR TABLE corrupts a MERGE table) fixed this bug too.
    However it revealed a new bug that crashed the server.
    
    Flushing a merge table at the moment when it is between open
    and attach of children crashed the server.
    
    The flushing thread wants to abort locks on the flushed table.
    It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
    on the TABLE object of the other thread.
    
    Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
    to accept non-attached children. ha_myisammrg::lock_count() returns
    the number of MyISAM tables in the MERGE table so that the memory
    allocation done by get_lock_data() is done correctly, even if the
    children become attached before ha_myisammrg::store_lock() is
    called. ha_myisammrg::store_lock() will not return any lock if the
    children are not attached.
    
    This is however a change in the handler interface. lock_count()
    can now return a higher number than store_lock() stores locks.
    This is more safe than the reverse implementation would be.
    get_lock_data() in the SQL layer is adjusted accordingly. It sets
    MYSQL_LOCK::lock_count based on the number of locks returned by
    the handler::store_lock() calls, not based on the numbers returned
    by the handler::lock_count() calls. The latter are only used for
    allocation of memory now.
    
    No test case. The test suite cannot reliably run FLUSH between
    lock_count() and store_lock() of another thread. The bug report
    contains a program that can repeat the problem with some
    probability.
    55aa6376
sql_base.cc 276 KB