1. 09 Jan, 2013 2 commits
  2. 08 Jan, 2013 3 commits
  3. 07 Jan, 2013 4 commits
  4. 04 Jan, 2013 5 commits
  5. 03 Jan, 2013 1 commit
  6. 02 Jan, 2013 4 commits
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · ce7e7a99
      Venkatesh Duggirala authored
      Merging fix from mysql-5.1
      ce7e7a99
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 39323920
      Venkatesh Duggirala authored
      Problem:If Disk becomes full while writing into the binlog,
      then the server instance hangs till someone frees the space.
      After user frees up the disk space, mysql server crashes
      with an assert (m_status != DA_EMPTY)
      
      Analysis: wait_for_free_space is being called in an
      infinite loop i.e., server instance will hang until
      someone frees up the space. So there is no need to
      set status bit in diagnostic area.
      
      Fix: Replace my_error/my_printf_error with
      sql_print_warning() which prints the warning in error log.
      
      include/my_sys.h:
        Provision to call sql_print_warning from mysys files
      mysys/errors.c:
        Replace my_error/my_printf_error with
        sql_print_warning() which prints the warning in error log.
      mysys/my_error.c:
        implementation of my_printf_warning
      mysys/my_write.c:
        Adding logic to break infinite loop in the simulation
      sql/mysqld.cc:
        Provision to call sql_print_warning from mysys files
      39323920
    • Marc Alff's avatar
      Bug#16060864 SEGMENTATION FAULT IN PERFORMANCE_SCHEMA WITH HISTORY SIZE 0 · cc2df006
      Marc Alff authored
      Before this fix, configuring the server with:
      - performance_schema_events_waits_history_size=0
      - performance_schema_events_waits_history_long_size=0
      could cause a crash in the performance schema.
      
      These settings to 0 are intended to be valid and supported,
      and are in fact working properly in mysql 5.6 and up already.
      
      This fix backports the code fix and test cases from mysql 5.6
      to the mysql 5.5 release.
      cc2df006
    • Kent Boortz's avatar
      5ff0148e
  7. 01 Jan, 2013 2 commits
  8. 29 Dec, 2012 2 commits
  9. 28 Dec, 2012 2 commits
  10. 27 Dec, 2012 4 commits
  11. 26 Dec, 2012 4 commits
  12. 24 Dec, 2012 4 commits
    • Annamalai Gurusami's avatar
      8d1923f4
    • Annamalai Gurusami's avatar
      Fixing a pb2 issue. There is some difference in the output in my local... · 76059a4a
      Annamalai Gurusami authored
      Fixing a pb2 issue.  There is some difference in the output in my local machine and pb2 machines in the explain output.  
      76059a4a
    • Chaithra Gopalareddy's avatar
      Merge from 5.1 · 777ac199
      Chaithra Gopalareddy authored
      777ac199
    • Chaithra Gopalareddy's avatar
      Bug#11757005: UNION CONVERTS UNSIGNED MEDIUMINT AND BIGINT · 259a5a30
      Chaithra Gopalareddy authored
                    TO SIGNED
      Problem:
      When we are joining types (of fields) in case of a union, we usually
      upgrade the datatypes to the largest present in the query.
      In case of mediumint, it is not happening.
      Analysis:
      When joined with types LONG and LONGLONG, mediumint should get
      upgraded to LONG and LONGLONG respectively.
      W.r.t the given query, constant '1' will be created as a LONGLONG
      internally and SIGNED flag is enabled. As a result, while combining
      types for the field, LONGLONG along with MEDIUMINT gets converted
      to LONG first. LONG with MEDIUMINT(of the third select) gets converted
      to MEDIUMINT. SIGNED FLAG would be that of the first field's.
      As a result, the final result would be SIGNED MEDIUMINT.
      Fix:
      While joining types, MEDIUMINT with LONGLONG and MEDIUMINT with LONG
      is converted to LONGLONG and LONG respectively. Also, made some 
      changes for FLOAT and DOUBLE.
      
      
      sql/field.cc:
        Changed merge types for MEDIUMINT.
      259a5a30
  13. 21 Dec, 2012 3 commits
    • Tor Didriksen's avatar
      merge 5.1 => 5.5 · 8aa2a2d6
      Tor Didriksen authored
      8aa2a2d6
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 96c373c5
      Roy Lyseng authored
      The problem is a shift operation that is not 64-bit safe.
      The consequence is that used tables information for a join with 32 tables
      or more will be incorrect.
      
      Fixed by adding a type cast in Item_sum::update_used_tables().
      
      Also used the opportunity to fix some other potential bugs by adding an
      explicit type-cast to an integer in a left-shift operation.
      Some of them were quite harmless, but was fixed in order to get the same
      signed-ness as the other operand of the operation it was used in.
      
      sql/item_cmpfunc.cc
        Adjusted signed-ness for some integers in left-shift.
      
      sql/item_subselect.cc
        Added type-cast to nesting_map (which is a 32/64 bit type, so
        potential bug for deeply nested queries).
      
      sql/item_sum.cc
        Added type-cast to nesting_map (32/64-bit type) and table_map
        (64-bit type).
      
      sql/opt_range.cc
        Added type-cast to ulonglong (which is a 64-bit type).
      
      sql/sql_base.cc
        Added type-cast to nesting_map (which is a 32/64-bit type).
      
      sql/sql_select.cc
        Added type-cast to nesting_map (32/64-bit type) and key_part_map
        (64-bit type).
      
      sql/strfunc.cc
        Changed type-cast from longlong to ulonglong, to preserve signed-ness.
      96c373c5
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 56db769e
      prabakaran thirumalai authored
      merge from 5.1
      56db769e