1. 10 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #50998 "Deadlock in MDL code during test · 96344bef
      Dmitry Lenev authored
      rqg_mdl_stability".
      
      When start of statement's waiting on a metadata lock 
      created more than one loop in waiters graph server might 
      have entered deadlock condition.
      
      The problem was that in the case described above MDL deadlock 
      detector had to perform several searches for deadlock but
      forgot to reset Deadlock_detection_context before performing 
      new search. 
      Failure to do so has broken assumption in code resposible for 
      choosing victim that if Deadlock_detection_context::victim
      is set we also have read lock on m_waiting_for_lock for this
      context. As result this lock could have been unlocked more
      times than it was acquired which corrupted rwlock's state
      which led to server deadlock.
      
      This fix ensures that such reset is done before each attempt
      to find a deadlock.
      
      mysql-test/r/mdl_sync.result:
        Added test for bug #50998 "Deadlock in MDL code during test
        rqg_mdl_stability" as well as coverage for the case when
        addition of statement waiting for metadata lock adds several
        loops in the waiters graph and therefore several searches
        for deadlock should be performed by MDL deadlock detector.
      mysql-test/t/mdl_sync.test:
        Added test for bug #50998 "Deadlock in MDL code during test
        rqg_mdl_stability" as well as coverage for the case when
        addition of statement waiting for metadata lock adds several
        loops in the waiters graph and therefore several searches
        for deadlock should be performed by MDL deadlock detector.
      sql/mdl.cc:
        Ensure that in cases when MDL deadlock detector had to
        perform several searches for deadlock because several loops
        in waiters graph are possible we reset
        Deadlock_detection_context before performing each search.
        Failure to do so has broken assumption in code resposible
        for choosing victim that if Deadlock_detection_context::victim
        is set we also have read lock on m_waiting_for_lock for this
        context. As result this lock could have been unlocked more
        times than it was acquired which corrupted rwlock's state
        (no one was able to acquire write lock on it anymore).
      96344bef
  2. 09 Feb, 2010 5 commits
  3. 08 Feb, 2010 4 commits
    • Joerg Bruehe's avatar
      Upmerge "configure.in" text change from 5.1 to 5.5 ("trunk"), · 5d115bbe
      Joerg Bruehe authored
      fixing bug#50950.
      5d115bbe
    • Joerg Bruehe's avatar
      Upmerge "configure.in" text change from 5.0 to 5.1, · ed75cda3
      Joerg Bruehe authored
      fixing bug#50950.
      ed75cda3
    • Dmitry Lenev's avatar
      Fix for bug #50913 "Deadlock between open_and_lock_tables_derived · 8018ec5a
      Dmitry Lenev authored
      and MDL".
      
      Concurrent execution of a multi-DELETE statement and ALTER
      TABLE statement which affected one of the tables used in
      the multi-DELETE sometimes led to deadlock.
      Similar deadlocks might have occured when one performed
      INSERT/UPDATE/DELETE on a view and concurrently executed
      ALTER TABLE for the view's underlying table, or when one
      concurrently executed TRUNCATE TABLE for InnoDB table and
      ALTER TABLE for the same table.
      
      These deadlocks were caused by a discrepancy between types of
      metadata and thr_lock.cc locks acquired by those statements.
      
      What happened was that multi-DELETE/TRUNCATE/DML-through-the-
      view statement in the first connection acquired SR lock on a
      table, then ALTER TABLE would come in in the second connection
      and acquire SNW metadata lock and TL_WRITE_ALLOW_READ
      thr_lock.c lock and then would start waiting for the first
      connection during lock upgrade. After that the statement in
      the first connection would try to acquire TL_WRITE lock on
      table and would start waiting for the second connection,
      creating a deadlock.
      
      This patch solves this problem by ensuring that we acquire
      SW metadata lock in all cases in which we acquiring write
      thr_lock.c lock. This guarantees that deadlocks like the
      one described above won't occur since all lock conflicts
      in such situation are resolved within MDL subsystem.
      
      This patch also adds assert which should guarantee that
      such situations won't arise in future.
      
      mysql-test/r/lock_multi.result:
        Added main test for bug #50913 "Deadlock between
        open_and_lock_tables_derived and MDL".
      mysql-test/r/mdl_sync.result:
        Added additional coverage for bug #50913 "Deadlock
        between open_and_lock_tables_derived and MDL".
      mysql-test/t/lock_multi.test:
        Added main test for bug #50913 "Deadlock between
        open_and_lock_tables_derived and MDL".
      mysql-test/t/mdl_sync.test:
        Added additional coverage for bug #50913 "Deadlock
        between open_and_lock_tables_derived and MDL".
      sql/lock.cc:
        Added assert that enforces that when we are locking
        a non-temporary table we have an appropriate type of
        metadata lock on this table.
      sql/mysql_priv.h:
        Added separate flag for open_tables() to be able specify that
        SH metadata locks on table to be open should be acquired.
        We can no longer use MYSQL_LOCK_IGNORE_FLUSH flag for this
        as in addition to use in I_S implementation it is also used
        for opening system tables. Since in the latter case we also
        acquire thr_lock.c locks using SH metadata lock in it instead
        of SR or SW locks may lead to deadlock.
      sql/sql_base.cc:
        When opening tables don't interpret MYSQL_LOCK_IGNORE_FLUSH
        flag as request to acquire SH metadata locks. This flag is
        also used for opening system tables for which we also take
        thr_lock.c locks and thus proper metadata lock to take in
        this case is SR or SW lock (otherwise deadlocks can occur).
        In cases when SH lock is really required (e.g. when tables
        are open by I_S implementation) we rely on that newly
        introduced MYSQL_OPEN_FORCE_SHARED_HIGH_PRIO_MDL flag is
        used.
      sql/sql_delete.cc:
        mysql_truncate_by_delete():
          Adjust type of metadata lock to be requested after changing
          type of thr_lock.c lock for table list element from one
          which was set in parser to TL_WRITE.
          This removes discrepancy between types of these locks which
          allowed deadlocks to creep in.
      sql/sql_handler.cc:
        When closing table which was open by HANDLER statement clear
        TABLE::open_by_handler flag. This allows to use this flag as
        a reliable indication that TABLE instance was open by HANDLER
        statement in assert which was added to mysql_lock_tables().
      sql/sql_parse.cc:
        multi_delete_set_locks_and_link_aux_tables():
          Adjust type of metadata lock to be requested after changing
          type of thr_lock.c lock for table list element from one
          which was set in parser to TL_WRITE.
          This removes discrepancy between types of these locks which
          allowed deadlocks to creep in.
      sql/sql_show.cc:
        Use newly introduced MYSQL_OPEN_FORCE_SHARED_HIGH_PRIO_MDL
        flag in order to acquire SH metadata locks when opening tables
        in I_S implementation.
      sql/sql_update.cc:
        Added comment explaining why in multi-update after deciding
        that we need weaker thr_lock.c lock on a table we don't
        downgrade metadata lock on it.
      sql/sql_view.cc:
        When merging view into main statement adjust type of metadata
        lock to be requested after changing type of thr_lock.c lock
        for table. This removes discrepancy between types of these
        locks which allowed deadlocks to creep in.
      8018ec5a
    • Joerg Bruehe's avatar
      Bug#50950 Obsolete reference to www.mysql.com · 72da6b31
      Joerg Bruehe authored
                      in message printed at end of configure
      
      New text for the success message of "configure".
      
      configure.in:
        The message must be changed to drop the "www.mysql.com" URL.
      72da6b31
  4. 06 Feb, 2010 3 commits
    • Konstantin Osipov's avatar
      Merge next-4284 -> next-4284-merge · 4d4eed65
      Konstantin Osipov authored
      4d4eed65
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · a72f90bc
      Konstantin Osipov authored
      mysql-test/t/disabled.def:
        Restore disabled ssl tests: SSL certificates were updated.
        Disable sp_sync.test, the test case can't work in next-4284.
      mysql-test/t/partition_innodb.test:
        Disable parsing of the test case for Bug#47343, 
        the test can not work in next-4284.
      mysql-test/t/ps_ddl.test:
        Update results (CREATE TABLE IF NOT EXISTS takes
        into account existence of the temporary table).
      a72f90bc
    • Jon Olav Hauglid's avatar
      Bug #50912 Assertion `ticket->m_type >= mdl_request->type' · 95c23861
      Jon Olav Hauglid authored
                 failed on HANDLER + I_S
      
      This assert was triggered when an I_S query tried to acquire a
      metadata lock on a table which was already locked by a HANDLER
      statement in the same connection.
      
      First the HANDLER took a MDL_SHARED lock. Afterwards, the I_S query
      requested a MDL_SHARED_HIGH_PRIO lock. The existing MDL_SHARED ticket
      is found in find_ticket() since it satisfies 
      ticket->has_stronger_or_equal_type(mdl_request->type) as MDL_SHARED
      and MDL_SHARED_HIGH_PRIO have equal strengths, just different priority.
      
      However, two asserts later check lock type strengths using relational
      operators (>= and <=) rather than MDL_ticket::has_stronger_or_equal_type().
      These asserts are triggered since MDL_SHARED >= MDL_SHARED_HIGH_PRIORITY
      is false (mapped to 1 and 2 respectively).
      
      This patch updates the asserts to use MDL_ticket::has_stronger_or_equal_type()
      rather than relational operators to check lock type strength.
      
      Test case added to include/handler.inc.
      95c23861
  5. 05 Feb, 2010 12 commits
  6. 04 Feb, 2010 11 commits
    • Konstantin Osipov's avatar
      A post-merge fix for next-mr -> next-4284 merge: · a6f80422
      Konstantin Osipov authored
      Make all mutexes and conditions of type mysql_mutex_t, mysql_cond_t,
      since it's now the expectation of THD::awake().
      a6f80422
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · e7b332ba
      Konstantin Osipov authored
      e7b332ba
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · 00dc9a6e
      Konstantin Osipov authored
      Cherry-pick a fix Bug#37148 from next-mr, to preserve
      file ids of the added files, and ensure that all the necessary
      changes have been pulled.
      
      Since initially Bug#37148 was null-merged into 6.0,
      the changeset that is now being cherry-picked was likewise
      null merged into next-4284.
      
      Now that Bug#37148 has been reapplied to 6.0, try to make
      it work with next-4284. This is also necessary to be able
      to pull other changes from 5.1-rep into next-4284.
      
      To resolve the merge issues use this changeset applied
      to 6.0:
      revid:jperkin@sun.com-20091216103628-ylhqf7s6yegui2t9
      revno: 3776.1.1
      committer: He Zhenxing <zhenxing.he@sun.com>
      branch nick: 6.0-codebase-bugfixing
      timestamp: Thu 2009-12-17 17:02:50 +0800
      message:
        Fix merge problem with Bug#37148
      
      
      
      00dc9a6e
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284-merge. · a9e22b58
      Konstantin Osipov authored
      a9e22b58
    • Dmitry Lenev's avatar
      Small clean-up in CREATE TABLE LIKE implementation. · 1edca1d7
      Dmitry Lenev authored
      Removed local variables which became unused when we
      have switched to new approach for CREATE TABLE LIKE
      (i.e. abondoned .FRM file copying) and were causing
      warnings during compilation.
      1edca1d7
    • unknown's avatar
      Raise version number after cloning 5.1.44 · 88519d1c
      unknown authored
      88519d1c
    • Georgi Kodinov's avatar
      merge · 404b3be1
      Georgi Kodinov authored
      404b3be1
    • Georgi Kodinov's avatar
      tree name change · b8db15fc
      Georgi Kodinov authored
      b8db15fc
    • Jon Olav Hauglid's avatar
      Bug #50821 Deadlock between LOCK TABLES and ALTER TABLE · a19377e0
      Jon Olav Hauglid authored
      This was a deadlock between ALTER TABLE and another DML statement
      (or LOCK TABLES ... READ). ALTER TABLE would wait trying to upgrade
      its lock to MDL_EXCLUSIVE and the DML statement would wait trying
      to acquire a TL_READ_NO_INSERT table level lock.
      
      This could happen if one connection first acquired a MDL_SHARED_READ
      lock on a table. In another connection ALTER TABLE is then started.
      ALTER TABLE eventually blocks trying to upgrade to MDL_EXCLUSIVE,
      but while holding a TL_WRITE_ALLOW_READ table level lock.
      
      If the first connection then tries to acquire TL_READ_NO_INSERT,
      it will block and we have a deadlock since neither connection can
      proceed.
      
      This patch fixes the problem by allowing TL_READ_NO_INSERT 
      locks to be granted if another connection holds TL_WRITE_ALLOW_READ
      on the same table. This will allow the DML statement to proceed
      such that it eventually can release its MDL lock which in turn
      makes ALTER TABLE able to proceed.
      
      Note that TL_READ_NO_INSERT was already partially compatible with
      TL_WRITE_ALLOW_READ as the latter would be granted if the former
      lock was held. This patch just makes the opposite true as well.
      
      Also note that since ALTER TABLE takes an upgradable MDL lock,
      there will be no starvation of ALTER TABLE statements by
      statements acquiring TL_READ or TL_READ_NO_INSERT.
      
      Test case added to lock_sync.test.
      a19377e0
    • Alexander Nozdrin's avatar
      61903751
    • Dmitry Lenev's avatar
      Improve concurrency in metadata locking subsystem by · f1f0228f
      Dmitry Lenev authored
      moving calculation of hash value when looking up
      MDL_lock objects in MDL_map out of critical section.
      f1f0228f
  7. 03 Feb, 2010 4 commits