1. 17 Aug, 2007 1 commit
  2. 16 Aug, 2007 1 commit
  3. 15 Aug, 2007 3 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #30396. · d790ec42
      igor@olga.mysql.com authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      d790ec42
    • evgen@moonbone.local's avatar
      mysql_client_test.c: · 222fddcb
      evgen@moonbone.local authored
        Post fix for the bug#29948.
      222fddcb
    • mhansson/martin@linux-st28.site's avatar
      bug#28570: handler::index_read() is called with different find_flag when · 1da8451d
      mhansson/martin@linux-st28.site authored
      ORDER BY is used
      
      The range analysis module did not correctly signal to the 
      handler that a range represents a ref (EQ_RANGE flag). This causes 
      non-range queries like 
      SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const 
      ORDER BY ... FOR UPDATE
      to wait for a lock unneccesarily if another running transaction uses
      SELECT ... FOR UPDATE on the same table.
      
      Fixed by setting EQ_RANGE for all range accesses that represent 
      an equality predicate. 
      1da8451d
  4. 14 Aug, 2007 3 commits
  5. 13 Aug, 2007 3 commits
  6. 10 Aug, 2007 1 commit
  7. 08 Aug, 2007 1 commit
  8. 06 Aug, 2007 8 commits
  9. 05 Aug, 2007 8 commits
    • kent@mysql.com/kent-amd64.(none)'s avatar
      mysql-test-run.pl: · 6ab4112c
      kent@mysql.com/kent-amd64.(none) authored
        Search "relwithdebinfo" directory in CMake Visual Studio build
        Search for "mysqld-debug" even in source tree
      6ab4112c
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · a8debc65
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug30219
      a8debc65
    • igor@olga.mysql.com's avatar
      Fix bug #30219. · 5f6df1b2
      igor@olga.mysql.com authored
      This bug manifested itself for queries with grouping by columns of
      the BIT type. It led to wrong comparisons of bit-field values and
      wrong result sets.
      Bit-field values never cannot be compared as binary values. Yet
      the class Field_bit had an implementation of the cmp method that
      compared bit-fields values as binary values. 
      Also the get_image and set_image methods of the base class Field 
      cannot be used for objects of the Field_bit class. 
      Now these methods are declared as virtual and specific implementations
      of the methods are provided for the class Field_bit.
      5f6df1b2
    • df@pippilotta.erinye.com's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build · 239f6aa3
      df@pippilotta.erinye.com authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
      239f6aa3
    • df@pippilotta.erinye.com's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0 · 17e76114
      df@pippilotta.erinye.com authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
      17e76114
    • df@pippilotta.erinye.com's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1 · 0285a32a
      df@pippilotta.erinye.com authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build
      0285a32a
    • dlenev@mockturtle.local's avatar
      Fix for bug #21281 "Pending write lock is incorrectly removed when its · a43431b3
      dlenev@mockturtle.local authored
      statement being KILLed".
      
      When statement which was trying to obtain write lock on then table and
      which was blocked by existing read lock was killed, concurrent statements
      that were trying to obtain read locks on the same table and that were
      blocked by the presence of this pending write lock were not woken up and
      had to wait until this first read lock goes away.
      
      This problem was caused by the fact that we forgot to wake up threads
      which pending requests could have been satisfied after removing lock
      request for the killed thread.
      
      The patch solves the problem by waking up those threads in such situation.
      
      Test for this bug will be added to 5.1 only as it has much better
      facilities for its implementation. Particularly, by using I_S.PROCESSLIST
      and wait_condition.inc script we can wait until thread will be blocked on
      certain table lock without relying on unconditional sleep (which usage
      increases time needed for test runs and might cause spurious test
      failures on slower platforms).
      a43431b3
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0 · d9373125
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-merge
      d9373125
  10. 04 Aug, 2007 2 commits
  11. 03 Aug, 2007 9 commits