1. 10 Sep, 2009 1 commit
  2. 09 Sep, 2009 2 commits
  3. 08 Sep, 2009 2 commits
  4. 07 Sep, 2009 1 commit
    • Sergey Petrunya's avatar
      Merge MySQL->MariaDB · 29f0dcb5
      Sergey Petrunya authored
      * Finished Monty and Jani's merge
      * Some InnoDB tests still fail (because it's old xtradb code run against
        newer testsuite). They are expected to go after mergning with the latest
        xtradb.
      29f0dcb5
  5. 24 Aug, 2009 1 commit
  6. 21 Aug, 2009 1 commit
  7. 20 Aug, 2009 4 commits
  8. 13 Aug, 2009 2 commits
  9. 12 Aug, 2009 5 commits
  10. 11 Aug, 2009 11 commits
  11. 10 Aug, 2009 5 commits
  12. 09 Aug, 2009 1 commit
  13. 08 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45010: invalid memory reads during parsing some strange statements · c7163c63
      Davi Arnaut authored
      The problem is that the lexer could inadvertently skip over the
      end of a query being parsed if it encountered a malformed multibyte
      character. A specially crated query string could cause the lexer
      to jump up to six bytes past the end of the query buffer. Another
      problem was that the laxer could use unfiltered user input as
      a signed array index for the parser maps (having upper and lower
      bounds 0 and 256 respectively).
      
      The solution is to ensure that the lexer only skips over well-formed
      multibyte characters and that the index value of the parser maps
      is always a unsigned value.
      
      mysql-test/r/ctype_recoding.result:
        Update test case result: ending backtick is not skipped over anymore.
      sql/sql_lex.cc:
        Characters being analyzed must be unsigned as they can be
        used as indexes for the parser maps. Only skip over if the
        string is a valid multi-byte sequence.
      tests/mysql_client_test.c:
        Add test case for Bug#45010
      c7163c63
  14. 07 Aug, 2009 1 commit
    • Martin Hansson's avatar
      Bug#46454: MySQL wrong index optimisation leads to incorrect result & crashes · 4c3917b6
      Martin Hansson authored
      Problem 1:
      When the 'Using index' optimization is used, the optimizer may still - after
      cost-based optimization - decide to use another index in order to avoid using
      a temporary table. But when this happens, the flag to the storage engine to 
      read index only (not table) was still set. Fixed by resetting the flag in the 
      storage engine and TABLE structure in the above scenario, unless the new index
      allows for the same optimization.
      Problem 2:
      When a 'ref' access method was employed by cost-based optimizer, (when the column
      is non-NULLable), it was assumed that it needed no initialization if 'quick' access
      methods (since they are based on range scan). When ORDER BY optimization overrides 
      the decision, however, it expects to have this initialized and hence crashes. 
      Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 
      'ref' access. 
      
      mysql-test/r/order_by.result:
        Bug#46454: Test result.
      mysql-test/t/order_by.test:
        Bug#46454: Test case.
      sql/sql_select.cc:
        Bug#46454: 
        Problem 1 fixed in make_join_select()
        Problem 2 fixed in test_if_skip_sort_order()
      sql/table.h:
        Bug#46454: Added comment to field.
      4c3917b6
  15. 06 Aug, 2009 2 commits