1. 05 Mar, 2013 1 commit
  2. 01 Mar, 2013 1 commit
  3. 28 Feb, 2013 2 commits
  4. 16 Jan, 2013 1 commit
  5. 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 · 1b2c2ab3
      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.
      
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Changed explain output: The explain now contains "Using where" since we
        have restored the select pointer after doing the filesort operation.
      sql/sql_select.cc:
        Change create_sort_index() so that it always sets the pointer to
        the select object to NULL. This is done in order to avoid that the
        select->quick object can be used when execution the main part of
        the select operation.
      sql/sql_select.h:
        New member in JOIN_TAB: saved_select. Used by create_sort_index to
        make a backup copy of the select pointer.
      1b2c2ab3
  6. 07 Jan, 2013 4 commits
  7. 04 Jan, 2013 5 commits
  8. 03 Jan, 2013 1 commit
  9. 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
  10. 01 Jan, 2013 2 commits
  11. 29 Dec, 2012 2 commits
  12. 28 Dec, 2012 2 commits
  13. 27 Dec, 2012 4 commits
  14. 26 Dec, 2012 4 commits
  15. 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
  16. 21 Dec, 2012 1 commit