• Jon Olav Hauglid's avatar
    Bug #57002 Assert in upgrade_shared_lock_to_exclusive() · fd7dd37e
    Jon Olav Hauglid authored
               for ALTER TABLE + MERGE tables
    
    The patch for Bug#56292 changed how metadata locks are taken for MERGE
    tables. After the patch, locking the MERGE table will also lock the
    children tables with the same metadata lock type. This means that 
    LOCK TABLES on a MERGE table also will implicitly do LOCK TABLES on
    the children tables.
    
    A consequence of this change, is that it is possible to do LOCK TABLES
    on a child table both explicitly and implicitly with the same statement
    and that these two locks can be of different strength. For example,
    LOCK TABLES child READ, merge WRITE.
    
    In LOCK TABLES mode, we are not allowed to take new locks and each
    statement must therefore try to find an existing TABLE instance with
    a suitable lock. The code that searched for a suitable TABLE instance,
    only considered table level locks. If a child table was locked twice,
    it was therefore possible for this code to find a TABLE instance with
    suitable table level locks but without suitable metadata lock.
    
    This problem caused the assert in upgrade_shared_lock_to_exclusive()
    to be triggered as it tried to upgrade a MDL_SHARED lock to
    EXCLUSIVE. The problem was a regression caused by the patch for
    Bug#56292.
    
    This patch fixes the problem by partially reverting the changes
    done by Bug#56292. Now, the children tables will only use the
    same metadata lock as the MERGE table for MDL_SHARED_NO_WRITE
    when not in locked tables mode. This means that LOCK TABLE
    on a MERGE table will not implicitly lock the children tables.
    This still fixes the original problem in Bug#56292 without
    causing a regression.
    
    Test case added to merge.test.
    fd7dd37e
merge.test 80.4 KB