1. 07 Mar, 2008 2 commits
  2. 06 Mar, 2008 1 commit
  3. 03 Mar, 2008 4 commits
    • 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
  4. 01 Mar, 2008 1 commit
  5. 29 Feb, 2008 7 commits
  6. 28 Feb, 2008 4 commits
    • 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
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · c8476efc
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B34747-5.0-opt
      c8476efc
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #34747: crash in debug assertion check after derived table · 0443189d
      gkodinov/kgeorge@magare.gmz authored
      Was a double-free of the Unique member of Item_func_group_concat.
      This was not causing a crash because the Unique is a descendent of
      Sql_alloc.
      Fixed to free the Unique only if it was allocated for the instance 
      of Item_func_group_concat it was referenced from
      0443189d
  7. 27 Feb, 2008 4 commits
  8. 26 Feb, 2008 1 commit
  9. 25 Feb, 2008 1 commit
    • kaa@kaamos.(none)'s avatar
      Fix for bug #33834: FRAC_SECOND: Applicability not clear in · 5a4e12cb
      kaa@kaamos.(none) authored
                          documentation
      
      While the manual mentions FRAC_SECOND only for the TIMESTAMPADD()
      function, it was also possible to use FRAC_SECOND with DATE_ADD(),
      DATE_SUB() and +/- INTERVAL.
      
      Fixed the parser to match the manual, i.e. using FRAC_SECOND for 
      anything other than TIMESTAMPADD()/TIMESTAMPDIFF() now produces a 
      syntax error.
      
      Additionally, the patch allows MICROSECOND to be used in TIMESTAMPADD/
      TIMESTAMPDIFF and marks FRAC_SECOND as deprecated.
      5a4e12cb
  10. 22 Feb, 2008 5 commits
  11. 20 Feb, 2008 2 commits
  12. 19 Feb, 2008 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30604: different flagging of time_zone_used in normal · 5b508f2d
      gkodinov/kgeorge@magare.gmz authored
        and ps-protocol
      Finding a routine should be a transparent operation as 
      far as the binary log is concerned.
      But it was influencing the binary log because of the TIMESTAMP
      column in the proc table.
      
      Fixed by preserving and restoring the time_zone usage flag when
      searching for a stored routine in the proc table.
      5b508f2d
  13. 18 Feb, 2008 1 commit
  14. 17 Feb, 2008 5 commits
  15. 15 Feb, 2008 1 commit