1. 26 May, 2011 7 commits
    • Tatjana Azundris Nuernberg's avatar
      auto-merge Bug#11745920 · f7fb620b
      Tatjana Azundris Nuernberg authored
      f7fb620b
    • Sven Sandberg's avatar
      Merged BUG#12574820 from 5.1 to 5.5 · 94b4850f
      Sven Sandberg authored
      Two conflicts resolved manually:
      Text conflict in sql/log.cc
      Text conflict in sql/mysqld.cc
      94b4850f
    • Sven Sandberg's avatar
      BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run · c98d3e04
      Sven Sandberg authored
      Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
      The correct order is first LOCK_thread_count and then LOCK_log. This function
      does it the other way around. This leads to deadlock when run in parallel
      with a thread that takes the two locks in correct order. For example, a thread
      that disconnects will take the locks in the correct order.
      Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
      first LOCK_thread_count and then LOCK_log.
      
      
      mysql-test/suite/binlog/r/binlog_reset_master.result:
        added result file
      mysql-test/suite/binlog/t/binlog_reset_master.test:
        Added test case that demonstrates deadlock because of wrong mutex order.
        The deadlock is between two threads:
         - RESET MASTER acquires mutexes in wrong order.
         - client thread shutdown code acquires mutexes in right order.
        Actually, this test case does not produce deadlock in 5.1, probably
        the client thread shutdown code does not hold both mutexes at the same
        time. However, the bug existed in 5.1 (mutexes are taken in the wrong
        order) so we push the test case to 5.1 too, to prevent future
        regressions.
      sql/log.cc:
        Change mutex acquisition to the correct order:
        first LOCK_thread_count, then LOCK_log.
      sql/mysqld.cc:
        Add debug code to synchronize test case.
      c98d3e04
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · 7cb11f0d
      Sergey Glukhov authored
      7cb11f0d
    • Sergey Glukhov's avatar
      Bug#12392636 ASSERTION FAILED: SCALE >= 0 && PRECISION > 0 && SCALE <= PRECISION · 6d2e6612
      Sergey Glukhov authored
      Assertion happens due to missing NULL value check in
      Item_func_round::fix_length_and_dec() function.
      The fix: added NULL value check for second parameter.
      
      
      mysql-test/r/func_math.result:
        test case
      mysql-test/t/func_math.test:
        test case
      sql/item_func.cc:
        added NULL value check for second parameter.
      6d2e6612
    • Bjorn Munch's avatar
      merge from 5.5-mtr · 33af0021
      Bjorn Munch authored
      33af0021
    • Tor Didriksen's avatar
      Don't check for FIONREAD on windows. · 80cfb573
      Tor Didriksen authored
      Execution of platforms tests are slow/flaky when building on windows.
      in PB:mysql-next-mr-opt-team on 2011-05-18 for win x86 debug_max, i see:
      -- Looking for FIONREAD
      -- Looking for FIONREAD - found
      and the build fails.
      80cfb573
  2. 25 May, 2011 8 commits
  3. 24 May, 2011 15 commits
  4. 23 May, 2011 3 commits
  5. 22 May, 2011 3 commits
  6. 21 May, 2011 4 commits