1. 07 Jan, 2013 4 commits
  2. 04 Jan, 2013 5 commits
  3. 03 Jan, 2013 1 commit
  4. 02 Jan, 2013 4 commits
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 2e851dd8
      Venkatesh Duggirala authored
      Merging fix from mysql-5.1
      2e851dd8
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 07947aab
      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
      07947aab
    • Marc Alff's avatar
      Bug#16060864 SEGMENTATION FAULT IN PERFORMANCE_SCHEMA WITH HISTORY SIZE 0 · c0c3e202
      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.
      c0c3e202
    • Kent Boortz's avatar
      dce5df9a
  5. 01 Jan, 2013 2 commits
  6. 29 Dec, 2012 2 commits
  7. 28 Dec, 2012 2 commits
  8. 27 Dec, 2012 4 commits
  9. 26 Dec, 2012 4 commits
  10. 24 Dec, 2012 4 commits
    • Annamalai Gurusami's avatar
      fbf130b4
    • Annamalai Gurusami's avatar
      Fixing a pb2 issue. There is some difference in the output in my local... · db0c4414
      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.  
      db0c4414
    • Chaithra Gopalareddy's avatar
      Merge from 5.1 · 7fb06bff
      Chaithra Gopalareddy authored
      7fb06bff
    • Chaithra Gopalareddy's avatar
      Bug#11757005: UNION CONVERTS UNSIGNED MEDIUMINT AND BIGINT · ac305e7d
      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.
      ac305e7d
  11. 21 Dec, 2012 4 commits
    • Tor Didriksen's avatar
      merge 5.1 => 5.5 · 8e615550
      Tor Didriksen authored
      8e615550
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 7d11d6db
      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.
      7d11d6db
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · d71f733c
      prabakaran thirumalai authored
      merge from 5.1
      d71f733c
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 581ab7aa
      prabakaran thirumalai authored
      Analysis:
      When thread cache is enabled, it does not properly initialize
      thd->start_utime when a thread is picked from the thread cache.
      This breaks the quota management mechanism. 
      THD::time_out_user_resource_limits() resets 
      m_user_connect->conn_per_hour to 0 based on thd->start_utime
      
      Fix:
      Initialize start_utime when cached thread is reused.
      
      Notes:
      Enabled back tests which were disabled because of this issue.
      581ab7aa
  12. 20 Dec, 2012 3 commits
    • Annamalai Gurusami's avatar
      Bug #13819630 ARCHIVE TABLE WITH 1000+ PARTITIONS CRASHES SERVER · b675abcd
      Annamalai Gurusami authored
      ON "DROP TABLE"
      
      In the function ha_archive::write_row(), there is an error code path
      that exits the function without releasing the mutex that was acquired
      earlier.  
      
      rb#1743 approved by ramil.
      b675abcd
    • Tor Didriksen's avatar
      Bug#16027468 ADDRESSSANITIZER BUG IN MYSQLTEST · f648e974
      Tor Didriksen authored
      DBUG_ENTER and DBUG_LEAVE must *always* match,
      otherwise all subsequent DBUG_ENTER calls will 
      be poking into undefined stack frames.
      f648e974
    • Annamalai Gurusami's avatar
      Bug #14556349 RENAME OF COMPRESSED TABLE AND INSERT BUFFER MERGE CAUSE · f36da178
      Annamalai Gurusami authored
      HANG
      
      Problem Statement:
      
      When the operation RENAME TABLE is about rename the tablespace of the
      table, it will stop all i/o operations on the tablespace temporarily.
      For this the fil_space_t::stop_ios member is used.
      
      Once the fil_space_t::stop_ios member is set to TRUE in the RENAME
      TABLE operation, it is expected that no new i/o operation will be done
      on the tablespace and all pending i/o operation can be completed on
      the tablespace.
      
      If the pending i/o operations initiate any new i/o operations then
      there will be deadlock.  The RENAME TABLE operation will be waiting
      for pending i/o on the tablespace to be completed, and the pending i/o
      operations will be waiting on the RENAME TABLE operation to set the
      file_space_t::stop_ios flag to be set to FALSE.
      
      But in the given scenario the pending i/o operations did not initiate
      new i/o.  But they where still unnecessarily checking the
      fil_space_t::stop_ios flag.  This resulted in deadlock.
      
      Solution:
      
      I noticed that this deadlock happens in fil_space_get_size() and
      fil_space_get_zip_size() in the i/o threads.  These functions check
      the stop_ios flag even when no i/o will be initiated.  I modified
      these functions to ensure that they check the stop_ios flag only when
      they will be initiating an i/o operation.  This solves the problem.
      
      rb://1635 (mysql-5.5)
      rb://1660 (mysql-trunk) approved by Inaam, Jimmy, and ima.
      f36da178
  13. 19 Dec, 2012 1 commit