• Konstantin Osipov's avatar
    Backport of: · 1ee8a588
    Konstantin Osipov authored
    ------------------------------------------------------------
    revno: 2476.784.3
    committer: davi@moksha.local
    timestamp: Tue 2007-10-02 21:27:31 -0300
    message:
    Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
            
    When a client (connection) holds a lock on a table and attempts to
    drop (obtain a exclusive lock) on a second table that is already
    held by a second client and the second client then attempts to
    drop the table that is held by the first client, leads to a
    circular wait deadlock. This scenario is very similar to trying to
    drop (or rename) a table while holding read locks and are
    correctly forbidden.
            
    The solution is to allow a drop table operation to continue only
    if the table being dropped is write (exclusively) locked, or if
    the table is temporary, or if the client is not holding any
    locks. Using this scheme prevents the creation of a circular
    chain in which each client is waiting for one table that the
    next client in the chain is holding.
                
    This is incompatible change, as can be seen by number of tests
    cases that needed to be fixed, but is consistent with respect to
    behavior of the different scenarios in which the circular wait
    might happen.
    1ee8a588
drop.result 4.38 KB