1. 07 Apr, 2011 7 commits
  2. 06 Apr, 2011 1 commit
  3. 05 Apr, 2011 1 commit
  4. 04 Apr, 2011 4 commits
  5. 02 Apr, 2011 1 commit
  6. 31 Mar, 2011 4 commits
    • Gleb Shchepa's avatar
      Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS · 7aa81e2a
      Gleb Shchepa authored
      In the string context the MIN() and MAX() functions don't take
      into account the unsignedness of the UNSIGNED BIGINT argument
      column.
      
      I.e.:
              CREATE TABLE t1 (a BIGINT UNSIGNED);
              INSERT INTO t1 VALUES (18446668621106209655);
              SELECT CONCAT(MAX(a)) FROM t1;
      
      returns -75452603341961.
      
      
      mysql-test/r/func_group.result:
        Test case for bug #11766094.
      mysql-test/t/func_group.test:
        Test case for bug #11766094.
      sql/item.cc:
        Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS
        
        The Item_cache_int::val_str() method has been modified to
        take into account the unsigned_flag value when converting
        data to string.
      7aa81e2a
    • Georgi Kodinov's avatar
      Merged the fix for bug #11936829 to 5.5.11 release · 6d849b93
      Georgi Kodinov authored
      Bug #11936829: DIFF. BETWEEN MYSQL.USER (AUTHENTICATION_STRING) IN 
        FRESH AND UPGRADED 5.5.11
                   
      There was no modification for pre 5.5.11 builds that had 
      authentication_string.  Thus the column was not upgraded 
      by mysql_upgrade.
                               
      Fixed by adding an ALTER TABLE MODIFY to update an existing 
      column to the latest type version.
                                           
      Test suite added.
      6d849b93
    • Mattias Jonsson's avatar
      merge · 8e2b0dc6
      Mattias Jonsson authored
      8e2b0dc6
    • Mattias Jonsson's avatar
      92c6bc5e
  7. 30 Mar, 2011 7 commits
    • Magne Mahre's avatar
      Null merge 5.1->5.5 · d9a3c073
      Magne Mahre authored
      d9a3c073
    • Magne Mahre's avatar
      Fix-up after commit of Bug#11900714 · b8faa8f2
      Magne Mahre authored
      The patch fixes a build problem on MacOSX, where
      the compiler complains about unused parameters.
      b8faa8f2
    • Marko Mäkelä's avatar
      e2f14878
    • Marko Mäkelä's avatar
      Bug#11877216 InnoDB too eager to commit suicide on a busy server · ddec6ecd
      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
      ddec6ecd
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · abbe33eb
      Sergey Glukhov authored
      abbe33eb
    • Sergey Glukhov's avatar
      Bug#11766124 59164: VALGRIND: UNINITIALIZED VALUE IN NUMBER_TO_DATETIME · a7d383cb
      Sergey Glukhov authored
      Valgrind warning happens due to missing NULL value check in
      Item::get_date. The fix is to add this check.
      
      
      mysql-test/r/func_time.result:
        test case
      mysql-test/t/func_time.test:
        test case
      sql/item.cc:
        added check for NULL value
      a7d383cb
    • Sergey Glukhov's avatar
      Bug#11766126 59166: ANOTHER DATETIME VALGRIND UNINITIALIZED WARNING · 3b7f0445
      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.
      
      
      mysql-test/r/func_time.result:
        test case
      mysql-test/t/func_time.test:
        test case
      sql/item_timefunc.h:
        check null value before result string calculation.
      3b7f0445
  8. 29 Mar, 2011 3 commits
    • Magne Mahre's avatar
      Bug#11933945 REMOVE LGPL LICENSED FILES IN MYSQL 5.5 · 517c5c24
      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) 
      517c5c24
    • Jon Olav Hauglid's avatar
      Null merge from mysql-5.1 to mysql-5.5 · f239fa30
      Jon Olav Hauglid authored
      f239fa30
    • Jon Olav Hauglid's avatar
      Bug# 11763784 (former 56541) · 4e26a41f
      Jon Olav Hauglid authored
      ASSERTION TABLE->DB_STAT FAILED IN
      SQL_BASE.CC::OPEN_TABLE() DURING I_S Q
      
      This assert could be triggered if a statement requiring a name
      lock on a table (e.g. DROP TRIGGER) executed concurrently
      with an I_S query which also used the table.
      
      One connection first started an I_S query that opened a given table.
      Then another connection started a statement requiring a name lock
      on the same table. This statement was blocked since the table was
      in use by the I_S query. When the I_S query resumed and tried to
      open the table again as part of get_all_tables(), it would encounter
      a table instance with an old version number representing the pending
      name lock. Since I_S queries ignore version checks and thus pending
      name locks, it would try to continue. This caused it to encounter
      the assert. The assert checked that the TABLE instance found with a
      different version, was a real, open table. However, since this TABLE
      instance instead represented a pending name lock, the check would
      fail and trigger the assert.
      
      This patch fixes the problem by removing the assert. It is ok for
      TABLE::db_stat to be 0 in this case since the TABLE instance can
      represent a pending name lock.
      
      Test case added to lock_sync.test.
      4e26a41f
  9. 28 Mar, 2011 12 commits