1. 19 Jun, 2009 1 commit
    • Matthias Leich's avatar
      Fix for Bug#40545, Bug#40209, Bug#40618, Bug#38346 · eb910845
      Matthias Leich authored
        Details:
        - Limit the queries to character sets and collations
          which are most probably available in all build types.
          But try to preserve the intention of the tests.
        - Remove the variants adjusted to some build types.
      
        Note:
        1. The results of the review by Bar are included.
        2. I am not able to check the correctness of this patch
           on any existing build type and any MySQL version.
           So it could happen that the new test fails somewhere.
      eb910845
  2. 28 Apr, 2009 1 commit
    • Gleb Shchepa's avatar
      backport from 6.0: · fa01a4ed
      Gleb Shchepa authored
      Bug #40925: Equality propagation takes non indexed attribute
      
      Query execution plans and execution time of queries like
      
        select a, b, c from t1
          where a > '2008-11-21' and b = a limit 10
      
      depended on the order of equality operator parameters:
      "b = a" and "a = b" are not same. 
      
      
      An equality propagation algorithm has been fixed:
      the substitute_for_best_equal_field function should not
      substitute a field for an equal field if both fields belong
      to the same table.
      fa01a4ed
  3. 24 Apr, 2009 5 commits
  4. 23 Apr, 2009 1 commit
  5. 21 Apr, 2009 1 commit
    • Sergey Vojtovich's avatar
      BUG#36966 - mysqldump.test fails in pushbuild · 90449829
      Sergey Vojtovich authored
      mysqldump.test is designed to run with concurrent inserts
      disabled. It is disabling concurrent inserts at the very
      beginning of the test case, and re-enables them at the
      bottom of the test. But for some reason (likely incorrect
      merge) we enable concurrent inserts in the middle of the test.
      
      The problem is fixed by enabling concurrent inserts only
      at the bottom of the test case.
      90449829
  6. 17 Apr, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #35087: Inserting duplicate values at one time with DES_ENCRYPT leads · 4783b2e1
      Georgi Kodinov authored
        to wrong results
            
      3 problems found with DES_ENCRYPT/DES_DECRYPT :
      
      1. The max length was not calculated properly. Fixed in fix_length_and_dec()
      2. DES_ENCRYPT had a side effect of sometimes reallocating and changing 
      the value of its argument. Fixed by explicitly pre-allocating the necessary
      space to pad the argument with trailing '*' (stars) when calculating the 
      DES digest.
      3. in DES_ENCRYPT the string buffer for the result value was not 
      reallocated to the correct size and only string length was assigned to it. 
      Fixed by making sure there's enough space to hold the result.
      4783b2e1
    • Sergey Glukhov's avatar
      Bug#44151 using handler commands on information_schema tables crashes server · 4fbfa8db
      Sergey Glukhov authored
      information schema tables are based on internal tmp tables which are removed
      after each statement execution. So HANDLER comands can not be used with
      information schema.
      4fbfa8db
  7. 16 Apr, 2009 2 commits
  8. 14 Apr, 2009 1 commit
  9. 09 Apr, 2009 6 commits
  10. 08 Apr, 2009 3 commits
  11. 07 Apr, 2009 2 commits
    • Satya B's avatar
      merge to latest 5.0-bugteam · 87bedb59
      Satya B authored
      87bedb59
    • Satya B's avatar
      Fix for Bug #43973 - backup_myisam.test fails on 6.0-bugteam · c045d1dc
      Satya B authored
            
      The test started failing following the push for BUG#41541.
      Some of the algorithms access bytes beyond the input data
      and this can affect up to one byte less than "word size"
      which is BITS_SAVED / 8. 
            
      Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
      (i.e. Memory Segment #2) to avoid accessing un-allocated data.
      c045d1dc
  12. 03 Apr, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · aebaf079
      Davi Arnaut authored
      The problem is that a SELECT .. FOR UPDATE statement might open
      a table and later wait for a impeding global read lock without
      noticing whether it is holding a table that is being waited upon
      the the flush phase of the process that took the global read
      lock.
      
      The same problem also affected the following statements:
      
      LOCK TABLES .. WRITE
      UPDATE .. SET (update and multi-table update)
      TRUNCATE TABLE ..
      LOAD DATA ..
      
      The solution is to make the above statements wait for a impending
      global read lock before opening the tables. If there is no
      impending global read lock, the statement raises a temporary
      protection against global read locks and progresses smoothly
      towards completion.
      
      Important notice: the patch does not try to address all possible
      cases, only those which are common and can be fixed unintrusively
      enough for 5.0.
      aebaf079
  13. 02 Apr, 2009 3 commits
  14. 01 Apr, 2009 4 commits
  15. 31 Mar, 2009 2 commits
  16. 30 Mar, 2009 3 commits
  17. 27 Mar, 2009 2 commits