1. 15 Jan, 2013 1 commit
  2. 14 Jan, 2013 5 commits
    • Neeraj Bisht's avatar
      · 1a951e71
      Neeraj Bisht authored
      BUG#14303860 - EXECUTING A SELECT QUERY WITH TOO 
      MANY WILDCARDS CAUSES A SEGFAULT
            Back port from 5.6 and trunk
      1a951e71
    • Olav Sandstaa's avatar
      Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY · e810f7f4
      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.
      e810f7f4
    • Neeraj Bisht's avatar
      BUG#14303860 - EXECUTING A SELECT QUERY WITH TOO · 78664f54
      Neeraj Bisht authored
      MANY WILDCARDS CAUSES A SEGFAULT
      
      Back port from 5.6 and trunk
      78664f54
    • Krunal Bauskar krunal.bauskar@oracle.com's avatar
    • Krunal Bauskar krunal.bauskar@oracle.com's avatar
      - BUG#1608883: KILLING A QUERY INSIDE INNODB CAUSES IT TO EVENTUALLY CRASH · e47f3943
        WITH AN ASSERTION
      
        Recently we added check to handle kill query signal for long operating
        queries. 
        While the query interruption is reported it must to ensure cursor is restore
        to proper state for HANDLER interface to work correctly. 
        Normal select query will not face this problem, as on recieving interrupt,
        select query is aborted and new select query result in re-initialization
        (including cursor).
      
        rb://1836. Approved by Marko.
      e47f3943
  3. 12 Jan, 2013 2 commits
    • Nisha Gopalakrishnan's avatar
      BUG#11757250: REPLACE(...) INSIDE A STORED PROCEDURE. · b4b960fc
      Nisha Gopalakrishnan authored
      Merge from 5.1 to 5.5
      b4b960fc
    • Nisha Gopalakrishnan's avatar
      BUG#11757250: REPLACE(...) INSIDE A STORED PROCEDURE. · 3d9d0e77
      Nisha Gopalakrishnan authored
      Analysis:
      --------
      
      REPLACE operation provides incorrect output when
      user variable is supplied as an argument and there
      are multiple rows on which the operation is performed.
      
      Consider the example below:
      
      SET @var='(( 00000000 ++ 00000000 ))';
      SELECT REPLACE(@var, '00000000', table_name) AS a FROM
      INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='mysql';
      
      Invalid output:
        +---------------------------------------+
        | REPLACE(@var, '00000000', TABLE_NAME) |
        +---------------------------------------+
        | (( columns_priv ++ columns_priv ))    |
        | (( columns_priv ++ columns_priv ))    |
            ......
            ......
        | (( columns_priv ++ columns_priv ))    |
        | (( columns_priv ++ columns_priv ))    |
        | (( columns_priv ++ columns_priv ))    |
        +---------------------------------------+
      
      The user argument supplied as the string to REPLACE
      operation is overwritten after the first iteration
      to '(( columns_priv ++ columns_priv ))'.
      The overwritten string after the first iteration
      is used for the subsequent REPLACE iteration. Since
      the pattern string is not found, it returns invalid
      output as mentioned above.
      
      Fix:
      ---
      If the Alloced_length is zero, realloc() and create a
      copy of the string which is then used for the REPLACE
      operation for every iteration.
      3d9d0e77
  4. 11 Jan, 2013 3 commits
    • Aditya A's avatar
      Bug#15843818 PARTITIONING BY RANGE WITH TO_DAYS ALWAYS · b11fe1b8
      Aditya A authored
                     INCLUDES FIRST PARTITION WHEN PRUNING
      
      [Merge from 5.1 to 5.5]
      b11fe1b8
    • Aditya A's avatar
      Bug#15843818 PARTITIONING BY RANGE WITH TO_DAYS ALWAYS · 01094a4b
      Aditya A authored
                     INCLUDES FIRST PARTITION WHEN PRUNING
      
      
      PROBLEM
      -------
      
      TO_DAYS()/TO_SECONDS() can return NULL for invalid dates which 
      was stored in the first partition ,therefore the first partition 
      was always included for the scan when range was specified.
      
      
      FIX
      ---
      
      The fix is a small optimization which we have included ,which will
      prune the scanning of NULL/first partition if the dates specified 
      in the range are valid and in the same year and month . TO_SECONDS()
      function is not supported in 5.1 so removed it from the fix and test
      scripts for mysql-5.1 version.
      01094a4b
    • Chaithra Gopalareddy's avatar
      Merge from 5.1 to 5.5 · feb36554
      Chaithra Gopalareddy authored
      feb36554
  5. 10 Jan, 2013 6 commits
    • Venkata Sidagam's avatar
      Bug #14553380 MYSQL C API LIBRARY EXITS AT NET_CLEAR AT NET_SERV.CC:223 · a40ea266
      Venkata Sidagam authored
      Problem description: When client loses the connection to the MySQL server or 
      if the server gets shutdown after mysql_stmt_prepare() then the next 
      mysql_stmt_prepare() will return an error(as expected) but consecutive call 
      mysql_stmt_execute(), will crash the client program. 
      The expected behavior would be, it should through an error.
      
      Analysis: The mysql_stmt_prepare() interns calls the function end_server() 
      and net->vio and net->buff are freed and set to NULL. Then the next call 
      mysql_stmt_execute() will interns call net_clear() where we are "net->vio" 
      with out validating it.
      
      Fix: we are validating the net->vio, before calling net_clear().
      a40ea266
    • Chaithra Gopalareddy's avatar
      Bug#11760726: LEFT JOIN OPTIMIZED INTO JOIN LEADS TO · b140c368
      Chaithra Gopalareddy authored
                    INCORRECT RESULTS
      
      This is a backport of fix for Bug#13068506.
      b140c368
    • Praveenkumar Hulakund's avatar
      Merge from 5.1 to 5.5 · d6aed37a
      Praveenkumar Hulakund authored
      d6aed37a
    • Praveenkumar Hulakund's avatar
      Bug#11749556: DEBUG ASSERTION WHEN ACCESSING A VIEW AND · 79438d75
      Praveenkumar Hulakund authored
                    AVAILABLE MEMORY IS TOO LOW 
      
      Analysis:
      ---------
      In function "mysql_make_view", "table->view" is initialized
      after parsing(using File_parser::parse) the view definition.
      If "::parse" function fails then control is moved to label 
      "err:". Here we have assert (table->view == thd->lex). 
      This assert fails if "::parse" function fails, as 
      table->view is not initialized yet.
      
      File_parser::parse fails if data being parsed is incorrect/
      corrupted or when memory allocation fails. In this scenario
      its failing because of failure in memory allocation.
      
      Fix:
      ---------
      In case of failure in function "File_parser::parse", moving
      to label "err:" is incorrect. Modified code to move
      to label "end:".
      79438d75
    • Annamalai Gurusami's avatar
      Bug #16004999 ASSERT STATE == TRX_STATE_NOT_STARTED, UNLOCK_ROW() · a69f4a05
      Annamalai Gurusami authored
      Problem:
      
      During the index intersect access method, the SQL layer will access one row,
      that satisfies a set of conditions, using an index i1.  And then it will try to
      access the same row, with other set of conditions using the next index i2.  If
      the fetch from i2 fails (we are talking about an error situation here and not
      simply an unmatched row situation), then it will unlock the row accessed via
      i1.  This will work in all situations except deadlock error.
      
      When a deadlock happens, InnoDB will rollback the transaction.  InnoDB intimates
      the SQL layer about this through the THD::transaction_rollback_request member.
      But this is not currently used by the SQL layer.
      
      Solution:
      
      When an error happens, the SQL layer must check the 
      THD::transaction_rollback_request member, before calling handler::unlock_row().
      We have also added a debug assert in ha_innobase::unlock_row() checking that
      it must be called only when the transaction is in active state.
      
      rb#1773 approved by Marko and Sunny.
      a69f4a05
    • prabakaran thirumalai's avatar
      Bug#16064876 MAIN.KILL FAILS OCCASIONALLY ON SOL10 SPARC64 · b36651dd
      prabakaran thirumalai authored
      Analysis:
      On solaris, killing a connection which waits on debug sync
      (waits on condition variable) is neglected. Subsequent kill
      connection to that thread succeeds. Debug sync code is not
      included in release build hence it is not an customer issue.
      Also verified that except this case, other cases succeed in
      main.kill test script. So moving this test to experimental
      state on solaris platform only in mysql-5.5 branch.
      b36651dd
  6. 09 Jan, 2013 2 commits
  7. 08 Jan, 2013 3 commits
  8. 07 Jan, 2013 4 commits
  9. 04 Jan, 2013 5 commits
  10. 03 Jan, 2013 1 commit
  11. 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
  12. 01 Jan, 2013 2 commits
  13. 29 Dec, 2012 2 commits