1. 19 Mar, 2008 1 commit
    • mhansson/martin@riffraff.(none)'s avatar
      Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY · 86db2a0c
      mhansson/martin@riffraff.(none) authored
        
      When swapping out heap I_S tables to disk, this is done after plan refinement.
      Thus, READ_RECORD::file will still point to the (deleted) heap handler at start
      of execution. This causes segmentation fault if join buffering is used and the 
      query is a star query where the result is found to be empty before accessing
      some table. In this case that table has not been initialized (i.e. had its 
      READ_RECORD re-initialized) before the cleanup routine tries to close the handler.
      Fixed by updating READ_RECORD::file when changing handler.
      86db2a0c
  2. 07 Mar, 2008 1 commit
  3. 29 Feb, 2008 6 commits
  4. 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
  5. 27 Feb, 2008 4 commits
  6. 26 Feb, 2008 1 commit
  7. 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
  8. 22 Feb, 2008 5 commits
  9. 20 Feb, 2008 2 commits
  10. 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
  11. 18 Feb, 2008 1 commit
  12. 17 Feb, 2008 5 commits
  13. 15 Feb, 2008 2 commits
  14. 14 Feb, 2008 1 commit
  15. 13 Feb, 2008 3 commits
  16. 12 Feb, 2008 2 commits