1. 17 Feb, 2010 1 commit
  2. 16 Feb, 2010 2 commits
  3. 15 Feb, 2010 10 commits
    • Konstantin Osipov's avatar
      A fix and a test case for Bug#47648 "main.merge fails sporadically". · dd510064
      Konstantin Osipov authored
      If a prepared statement used both a MyISAMMRG table and a stored 
      function or trigger, execution could fail with "No such table"
      error or crash. 
      The error would come from a failure of the MyISAMMRG engine
      to meet the expectations of the prelocking algorithm, 
      in particular maintain lex->query_tables_own_last pointer
      in sync with lex->query_tables_last pointer/the contents
      of lex->query_tables. When adding merge children, the merge
      engine would extend the table list. Then, when adding 
      prelocked tables, the prelocking algorithm would use a pointer
      to the last merge child to assign to lex->query_tables_own_last.
      Then, when merge children were removed at the end of
      open_tables(), lex->query_tables_own_last
      was not updated, and kept pointing
      to a removed merge child.
      
      The fix ensures that query_tables_own_last is always in
      sync with lex->query_tables_last.
      
      This is a regression introduced by WL#4144 and present only
      in next-4284 tree and 6.0.
      dd510064
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-next-4284. · 75479125
      Alexander Nozdrin authored
      75479125
    • Dmitry Lenev's avatar
      Fix for bug #51093 "Crash (possibly stack overflow) in · aab777ca
      Dmitry Lenev authored
      MDL_lock::find_deadlock".
      
      On some platforms deadlock detector in metadata locking 
      subsystem under certain conditions might have exhausted
      stack space causing server crashes.
      
      Particularly this caused failures of rqg_mdl_stability
      test on Solaris in PushBuild.
      
      During search for deadlock MDL deadlock detector could 
      sometimes encounter loop in the waiters graph in which 
      MDL_context which has started search for a deadlock 
      does not participate. In such case our algorithm will 
      continue looping assuming that either this deadlock will 
      be resolved by MDL_context which has created it (i.e.
      by one of loop participants) or maximum search depth
      will be reached. 
      Since max search depth was set to 1000 in the latter case 
      on platforms where each iteration of deadlock search 
      algorithm needs more than DEFAULT_STACK_SIZE/1000 bytes 
      of stack (around 192 bytes for 32-bit and around 256 bytes 
      for 64-bit platforms) we might have exhausted stack space.
      
      This patch solves this problem by reducing maximum search
      depth for MDL deadlock detector to 32. This should be safe
      at the moment as it is unlikely that each iteration of the 
      current deadlock detector algorithm will consume more than 
      1K of stack (thus total amount of stack required can't be
      more than 32K) and we require at least 80K of stack in order
      to open any table. Also this value should be (hopefully) big
      enough to not cause too much false deadlock errors (there
      is an anecdotal evidence that real-life deadlocks are
      typically shorter than that).
      
      Additional reasearch should be conducted in future in order
      to determine the more optimal value of maximum search depth.
      
      This patch does not include test case as existing
      rqg_mdl_stability test can serve as one.
      aab777ca
    • Jon Olav Hauglid's avatar
      Followup to Bug#45225 Locking: hang if drop table with no timeout · 96560266
      Jon Olav Hauglid authored
      This patch removes the unused server variable
      "table_lock_wait_timeout".
      96560266
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-next-4284. · e8d19b96
      Alexander Nozdrin authored
      e8d19b96
    • Alexander Nozdrin's avatar
      After-merge fix. · 04d77e8f
      Alexander Nozdrin authored
      04d77e8f
    • Dmitry Lenev's avatar
      Fix for bug #51136 "Crash in pthread_rwlock_rdlock on · 68710e2b
      Dmitry Lenev authored
      TEMPORARY + HANDLER + LOCK + SP".
      
      Server crashed when one: 
      1) Opened HANDLER or acquired global read lock
      2) Then locked one or several temporary tables with
         LOCK TABLES statement (but no base tables).
      3) Then issued any statement causing commit (explicit 
         or implicit).
      4) Issued statement which should have closed HANDLER
         or released global read lock.
         
      The problem was that when entering LOCK TABLES mode in the
      scenario described above we incorrectly set transactional
      MDL sentinel to zero. As result during commit all metadata 
      locks were released (including lock for open HANDLER or
      global metadata shared lock). Indeed, attempt to release
      metadata lock for the second time which happened during
      HANLDER CLOSE or during release of GLR caused crash.
      
      This patch fixes problem by changing MDL_context's
      set_trans_sentinel() method to set sentinel to correct 
      value (it should point to the most recent ticket).
      68710e2b
    • Alexander Nozdrin's avatar
      Manual merge from mysql-next-mr. · 6c32fa73
      Alexander Nozdrin authored
      Conflicts:
        - sql/log_event.cc
        - sql/sql_class.h
      6c32fa73
    • Dmitry Lenev's avatar
      Fix for bug #51134 "Crash in MDL_lock::destroy on a concurrent · 22bc48b2
      Dmitry Lenev authored
      DDL workload".
      
      When a RENAME TABLE or LOCK TABLE ... WRITE statement which
      mentioned the same table several times were aborted during 
      the process of acquring metadata locks (due to deadlock 
      which was discovered or because of KILL statement) server 
      might have crashed.
      
      When attempt to acquire all locks requested had failed we
      went through the list of requests and released locks which
      we have managed to acquire by that moment one by one. Since 
      in the scenario described above list of requests contained 
      duplicates this led to releasing the same ticket twice and 
      a crash as result.
      
      This patch solves the problem by employing different approach
      to releasing locks in case of failure to acquire all locks
      requested. 
      Now we take a MDL savepoint before starting acquiring locks 
      and simply rollback to it if things go bad.
      22bc48b2
    • Alexander Barkov's avatar
      WL#3090 Japanese Character Set adjustments · 0c61e7ab
      Alexander Barkov authored
      added:
        @ mysql-test/include/ctype_utf8_table.inc
          Adding a share file to populate all utf8 values [U+0000..U+FFFF]
      modified:
        @ include/m_ctype.h
          Introducing MB2 and MY_PUT_MB2 macros
      
        @ mysql-test/r/ctype_cp932_binlog_stm.result
        @ mysql-test/r/ctype_eucjpms.result
        @ mysql-test/r/ctype_sjis.result
        @ mysql-test/r/ctype_ujis.result
        @ mysql-test/t/ctype_cp932_binlog_stm.test
        @ mysql-test/t/ctype_eucjpms.test
        @ mysql-test/t/ctype_sjis.test
        @ mysql-test/t/ctype_ujis.test
          Adding test
      
        @ strings/ctype-cp932.c
        @ strings/ctype-eucjpms.c
        @ strings/ctype-sjis.c
        @ strings/ctype-ujis.c
          Adding new functions using Big-Table approach.
      0c61e7ab
  4. 14 Feb, 2010 2 commits
  5. 13 Feb, 2010 1 commit
  6. 12 Feb, 2010 16 commits
  7. 11 Feb, 2010 8 commits