1. 15 Jan, 2013 2 commits
    • Bjorn Munch's avatar
    • Olav Sandstaa's avatar
      Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY · 7cfc5962
      Olav Sandstaa authored
                           WITH A VARIABLE AND ORDER BY
              Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX
                  
      This is a fix for a regression introduced by Bug#12667154:
      Bug#12667154 attempted to fix a performance problem with subqueries
      that did filesort. For doing filesort, the optimizer creates a quick
      select object to use when building the sort index. This quick select
      object was deleted after the first call to create_sort_index(). Thus,
      for queries where the subquery was executed multiple times, the quick
      object was only used for the first execution. For all later executions
      of the subquery, filesort used a complete table scan for building the
      sort index. The fix for Bug#12667154 tried to fix this by not deleting
      the quick object after the first execution of create_sort_index() so
      that it would be re-used for building the sort index by the following
      executions of the subquery.
      
      This regression introduced in Bug#12667154 is that due to not deleting
      the quick select object after building the sort index, the quick
      object could in some cases be used also during the second phase of the
      execution of the subquery instead of using the created sort
      index. This caused wrong results to be returned.
      
      The fix for this issue is to delete the reference to the select object
      after it has been used in create_sort_index(). In this way the select 
      and quick objects will not be available when doing the second phase
      of the execution of the select operation. To ensure that the select
      object can be re-used for the following executions of the subquery
      we make a copy of the select pointer. This is used for restoring the
      select object after the select operation is completed.
      7cfc5962
  2. 07 Jan, 2013 4 commits
  3. 04 Jan, 2013 5 commits
  4. 03 Jan, 2013 1 commit
  5. 02 Jan, 2013 4 commits
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 8f9d5938
      Venkatesh Duggirala authored
      Merging fix from mysql-5.1
      8f9d5938
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · c72f687f
      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.
      c72f687f
    • Marc Alff's avatar
      Bug#16060864 SEGMENTATION FAULT IN PERFORMANCE_SCHEMA WITH HISTORY SIZE 0 · 7a846307
      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.
      7a846307
    • Kent Boortz's avatar
      5905fb4b
  6. 01 Jan, 2013 2 commits
  7. 29 Dec, 2012 2 commits
  8. 28 Dec, 2012 2 commits
  9. 27 Dec, 2012 4 commits
  10. 26 Dec, 2012 4 commits
  11. 24 Dec, 2012 4 commits
    • Annamalai Gurusami's avatar
      bf21d8a0
    • Annamalai Gurusami's avatar
      Fixing a pb2 issue. There is some difference in the output in my local... · d1dcbfd2
      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.  
      d1dcbfd2
    • Chaithra Gopalareddy's avatar
      Merge from 5.1 · 531dbab9
      Chaithra Gopalareddy authored
      531dbab9
    • Chaithra Gopalareddy's avatar
      Bug#11757005: UNION CONVERTS UNSIGNED MEDIUMINT AND BIGINT · adc973d5
      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.
      adc973d5
  12. 21 Dec, 2012 4 commits
    • Tor Didriksen's avatar
      merge 5.1 => 5.5 · a8bcaf49
      Tor Didriksen authored
      a8bcaf49
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 8b1d1cf5
      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.
      8b1d1cf5
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 7817b813
      prabakaran thirumalai authored
      merge from 5.1
      7817b813
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 0d5d4e5d
      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.
      0d5d4e5d
  13. 20 Dec, 2012 2 commits