1. 27 Mar, 2008 4 commits
  2. 14 Mar, 2008 1 commit
  3. 13 Mar, 2008 1 commit
  4. 12 Mar, 2008 4 commits
  5. 11 Mar, 2008 1 commit
  6. 10 Mar, 2008 3 commits
  7. 08 Mar, 2008 1 commit
  8. 07 Mar, 2008 3 commits
  9. 06 Mar, 2008 2 commits
  10. 05 Mar, 2008 2 commits
  11. 03 Mar, 2008 5 commits
    • joerg@trift2.'s avatar
      687d2131
    • sergefp@mysql.com's avatar
      BUG#34945: "ref_or_null queries that are null_rejecting and have a null value crash mysql" · b779af55
      sergefp@mysql.com authored
      - Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
        to before the late NULLs filtering code.
      - Backport function comments from 6.0.
      b779af55
    • kaa@kaamos.(none)'s avatar
      Merge kaamos.(none):/data/src/opt/bug31781/my50 · 232e9d3c
      kaa@kaamos.(none) authored
      into  kaamos.(none):/data/src/opt/mysql-5.0-opt
      232e9d3c
    • kaa@kaamos.(none)'s avatar
      Fix for bug #31781: multi-table UPDATE with temp-pool enabled fails · bd53f960
      kaa@kaamos.(none) authored
                          with errno 17
      
      my_create() did not perform any checks for the case when a file is
      successfully created by a call to open(), but the call to
      my_register_filename() later fails because the number of open files
      has exceeded the my_open_files limit. This can happen on platforms 
      which do not have getrlimit(), and hence we do not know the real limit
      for open files. In such a case an error was returned to a caller
      although the file has actually been created. Since callers assume
      my_create() to return an error only when it failed to create a file,
      they did not perform any cleanups, leaving an 'orphaned' file on the
      file system.
      
      Fixed by adding a check for the above case to my_create() and ensuring
      the newly created file is deleted before returning an error.
      
      Creating a deterministic test case in the test suite is impossible,
      because the exact steps required to reproduce the above situation
      depend on the platform and/or environment (OS per-user limits, queries
      executed by previous tests, startup parameters). The patch was
      manually tested on Windows using examples posted in the bug report.
      bd53f960
    • gluh@mysql.com/mgluh.(none)'s avatar
      test case fix · fc1ae077
      gluh@mysql.com/mgluh.(none) authored
      fc1ae077
  12. 02 Mar, 2008 1 commit
  13. 01 Mar, 2008 1 commit
  14. 29 Feb, 2008 7 commits
  15. 28 Feb, 2008 4 commits
    • davi@mysql.com/endora.local's avatar
      Post-merge fix for Bug 33851. The initialization order of members · 369c2493
      davi@mysql.com/endora.local authored
      must match the order which they were declared in the class definition. 
      369c2493
    • gshchepa/uchum@host.loc's avatar
      Merge host.loc:/home/uchum/work/PP/5.0-opt-34620 · 11a27f12
      gshchepa/uchum@host.loc authored
      into  host.loc:/home/uchum/work/5.0-opt
      11a27f12
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #34620: item_row.cc:50: Item_row::illegal_method_call(const char*): · c5110674
      gshchepa/uchum@host.loc authored
                        Assertion `0' failed
      
      If ROW item is a part of an expression that also has
      aggregate function calls (COUNT/SUM/AVG...), a
      "splitting" with an Item::split_sum_func2 function
      is applied to that ROW item.
      Current implementation of Item::split_sum_func2
      replaces this Item_row with a newly created
      Item_aggregate_ref reference to it.
      Then the row cache tries to work with the
      Item_aggregate_ref object as with the Item_row object:
      row cache calls row-emulation methods such as cols and
      element_index. Item_aggregate_ref (like it's parent
      Item_ref) inherits dummy implementations of those
      methods from the hierarchy root Item, and call to
      them leads to failed assertions and wrong data
      output.
      
      Row-emulation virtual functions (cols, element_index, addr,
      check_cols, null_inside and bring_value) of Item_ref have
      been overloaded to forward calls to an underlying item
      reference.
      
      c5110674
    • davi@mysql.com/endora.local's avatar
      Bug#33851 Passing UNSIGNED param to EXECUTE returns ERROR 1210 · 361262c7
      davi@mysql.com/endora.local authored
      The problem is that passing anything other than a integer to a limit
      clause in a prepared statement would fail. This limitation was introduced
      to avoid replication problems (e.g: replicating the statement with a
      string argument would cause a parse failure in the slave).
      
      The solution is to convert arguments to the limit clause to a integer
      value and use this converted value when persisting the query to the log.
      361262c7