1. 15 Apr, 2011 2 commits
  2. 14 Apr, 2011 2 commits
  3. 07 Apr, 2011 5 commits
  4. 06 Apr, 2011 1 commit
  5. 05 Apr, 2011 4 commits
  6. 04 Apr, 2011 4 commits
  7. 02 Apr, 2011 1 commit
  8. 31 Mar, 2011 11 commits
  9. 30 Mar, 2011 9 commits
    • Magne Mahre's avatar
      Null merge 5.1->5.5 · 40d579c6
      Magne Mahre authored
      40d579c6
    • Magne Mahre's avatar
      Fix-up after commit of Bug#11900714 · ffb98660
      Magne Mahre authored
      The patch fixes a build problem on MacOSX, where
      the compiler complains about unused parameters.
      ffb98660
    • Bjorn Munch's avatar
    • Bjorn Munch's avatar
    • Marko Mäkelä's avatar
      a120b650
    • Marko Mäkelä's avatar
      Bug#11877216 InnoDB too eager to commit suicide on a busy server · 4ffb26de
      Marko Mäkelä authored
      sync_array_print_long_waits(): Return the longest waiting thread ID
      and the longest waited-for lock. Only if those remain unchanged
      between calls in srv_error_monitor_thread(), increment
      fatal_cnt. Otherwise, reset fatal_cnt.
      
      Background: There is a built-in watchdog in InnoDB whose purpose is to
      kill the server when some thread is stuck waiting for a mutex or
      rw-lock. Before this fix, the logic was flawed.
      
      The function sync_array_print_long_waits() returns TRUE if it finds a
      lock wait that exceeds 10 minutes (srv_fatal_semaphore_wait_threshold).
      The function srv_error_monitor_thread() will kill the server if this
      happens 10 times in a row (fatal_cnt reaches 10), checked every 30
      seconds. This is wrong, because this situation does not mean that the
      server is hung. If the server is very busy for a little over 15
      minutes, it will be killed.
      
      Consider this example. Thread T1 is waiting for mutex M. Some time
      later, threads T2..Tn start waiting for the same mutex M. If T1 keeps
      waiting for 600 seconds, fatal_cnt will be incremented to 1. So far,
      so good. Now, if M is granted to T1, the server was obviously not
      stuck. But, T2..Tn keeps waiting, and their wait time will be longer
      than 600 seconds. If 5 minutes later, some Tn has still been waiting
      for more than 10 minutes for the mutex M, the server can be killed,
      even though it is not stuck.
      
      rb:622 approved by Jimmy Yang
      4ffb26de
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · 2c00c272
      Sergey Glukhov authored
      2c00c272
    • Sergey Glukhov's avatar
      Bug#11766124 59164: VALGRIND: UNINITIALIZED VALUE IN NUMBER_TO_DATETIME · fbed52c1
      Sergey Glukhov authored
      Valgrind warning happens due to missing NULL value check in
      Item::get_date. The fix is to add this check.
      fbed52c1
    • Sergey Glukhov's avatar
      Bug#11766126 59166: ANOTHER DATETIME VALGRIND UNINITIALIZED WARNING · 778a605a
      Sergey Glukhov authored
      Valgrind warning happens because null values check happens too late
      in Item_func_month::val_str(after result string calculation).The fix
      is to check null value before result string calculation.
      778a605a
  10. 29 Mar, 2011 1 commit
    • Magne Mahre's avatar
      Bug#11933945 REMOVE LGPL LICENSED FILES IN MYSQL 5.5 · 9b7799d5
      Magne Mahre authored
      The LGPL license is used in some legacy code, and to
      adhere to current licensing polity, we remove those
      files that are no longer used, and reorganize the
      remaining LGPL code so it will be GPL licensed from
      now on.
                  
      Note:  This patch only removed LGPL licensed files
             in MySQL 5.5 and later, and is the third of a 
             set of patches to remove LGPL from all trees.
             (See Bug# 11840513 for details) 
      9b7799d5