1. 26 May, 2011 7 commits
    • Tatjana Azundris Nuernberg's avatar
      auto-merge Bug#11745920 · e1b79597
      Tatjana Azundris Nuernberg authored
      e1b79597
    • Sven Sandberg's avatar
      Merged BUG#12574820 from 5.1 to 5.5 · add86aad
      Sven Sandberg authored
      Two conflicts resolved manually:
      Text conflict in sql/log.cc
      Text conflict in sql/mysqld.cc
      add86aad
    • Sven Sandberg's avatar
      BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run · de377681
      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.
      de377681
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · 9d42d36e
      Sergey Glukhov authored
      9d42d36e
    • Sergey Glukhov's avatar
      Bug#12392636 ASSERTION FAILED: SCALE >= 0 && PRECISION > 0 && SCALE <= PRECISION · 3efbf304
      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.
      3efbf304
    • Bjorn Munch's avatar
      merge from 5.5-mtr · b5009ee6
      Bjorn Munch authored
      b5009ee6
    • Tor Didriksen's avatar
      Don't check for FIONREAD on windows. · c41e8663
      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.
      c41e8663
  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