1. 08 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #50913 "Deadlock between open_and_lock_tables_derived · c7e7a7d2
      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.
      c7e7a7d2
  2. 06 Feb, 2010 3 commits
    • Konstantin Osipov's avatar
      Merge next-4284 -> next-4284-merge · f750b5f1
      Konstantin Osipov authored
      f750b5f1
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · 9c030fe5
      Konstantin Osipov authored
      9c030fe5
    • Jon Olav Hauglid's avatar
      Bug #50912 Assertion `ticket->m_type >= mdl_request->type' · a4819c5d
      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.
      a4819c5d
  3. 05 Feb, 2010 12 commits
  4. 04 Feb, 2010 11 commits
    • Konstantin Osipov's avatar
      A post-merge fix for next-mr -> next-4284 merge: · 5deaf55a
      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().
      5deaf55a
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · ad0f1f80
      Konstantin Osipov authored
      ad0f1f80
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · 06e1a73a
      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
      
      
      06e1a73a
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284-merge. · 89269e51
      Konstantin Osipov authored
      89269e51
    • Dmitry Lenev's avatar
      Small clean-up in CREATE TABLE LIKE implementation. · 8bba05e8
      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.
      8bba05e8
    • hery.ramilison@sun.com's avatar
      1c9ab8d6
    • Georgi Kodinov's avatar
      merge · 3e699a79
      Georgi Kodinov authored
      3e699a79
    • Georgi Kodinov's avatar
      tree name change · 21dbe024
      Georgi Kodinov authored
      21dbe024
    • Jon Olav Hauglid's avatar
      Bug #50821 Deadlock between LOCK TABLES and ALTER TABLE · 34de83e1
      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.
      34de83e1
    • Alexander Nozdrin's avatar
      9ee5543b
    • Dmitry Lenev's avatar
      Improve concurrency in metadata locking subsystem by · 967bd206
      Dmitry Lenev authored
      moving calculation of hash value when looking up
      MDL_lock objects in MDL_map out of critical section.
      967bd206
  5. 03 Feb, 2010 13 commits