1. 18 Apr, 2012 1 commit
    • Chaithra Gopalareddy's avatar
      Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER · 25f82f8a
      Chaithra Gopalareddy authored
                         ORDER BY COUNT(*) LIMIT.
      
      PROBLEM:
      With respect to problem in the bug description, we
      exhibit different behaviors for the two tables
      presented, because innodb statistics (rec_per_key
      in this case) are updated for the first table
      and not so for the second one. As a result the
      query plan gets changed in test_if_skip_sort_order
      to use 'index' scan. Hence the difference in the
      explain output. (NOTE: We can reproduce the problem
      with first table by reducing the number of tuples
      and changing the table structure)
      
      The varied output w.r.t the query on the second table
      is because of the result in the query plan change.
      When a query plan is changed to use 'index' scan,
      after the call to test_if_skip_sort_order, we set
      keyread to TRUE immedietly. If for some reason
      we drop this index scan for a filesort later on,
      we fetch only the keys not the entire tuple.
      As a result we would see junk values in the result set.
      
      Following is the code flow:
      
      Call test_if_skip_sort_order
      -Choose an index to give sorted output
      -If this is a covering index, set_keyread to TRUE
      -Set the scan to INDEX scan
      
      Call test_if_skip_sort_order second time
      -Index is not chosen (note that we do not pass the
      actual limit value second time. Hence we do not choose
      index scan second time which in itself is a bug fixed
      in 5.6 with WL#5558)
      -goto filesort
      
      Call filesort
      -Create quick range on a different index
      -Since keyread is set to TRUE, we fetch only the columns of
      the index
      -results in the required columns are not fetched
      
      FIX:
      Remove the call to set_keyread(TRUE) from
      test_if_skip_sort_order. The access function which is
      'join_read_first' or 'join_read_last' calls set_keyread anyways.
      
      
      mysql-test/r/func_group_innodb.result:
        Added test result for Bug#12713907
      mysql-test/t/func_group_innodb.test:
        Added test case for Bug#12713907
      sql/sql_select.cc:
        Remove the call to set_keyread as we do it from access
        functions 'join_read_first' and 'join_read_last'
      25f82f8a
  2. 17 Apr, 2012 1 commit
  3. 09 Apr, 2012 1 commit
  4. 06 Apr, 2012 1 commit
    • Mayank Prasad's avatar
      BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD · fe3f7993
      Mayank Prasad authored
      Background : 
      In mysql-5.1, in a fix for bug#47485, code has been changed for 
      mysql client (libmysql/libmysql.c) but corresponding code was not
      changed for embedded mysql. In that code change, after execution
      of a statement, mysql_stmt_store_result() checks for mysql->state
      to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of
      MYSQL_STATUS_GET_RESULT (earlier).
      
      Reason:
      In embedded mysql code, after execution, mysql->state was not
      set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing
      OUT_OF_SYNC error.
      
      Fix:
      Fixed the code in libmysqld/lib_sql.cc to have mysql->state
      to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution.
      
      fe3f7993
  5. 28 Mar, 2012 3 commits
    • Praveenkumar Hulakund's avatar
      Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVE · f3d5127f
      Praveenkumar Hulakund authored
      Analysis:
      -------------------------------
      According to the Manual
      (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
      "Column, index, stored routine, and event names are not case sensitive on any
      platform, nor are column aliases."
      
      In other words, 'lower_case_table_names' does not affect the behaviour of 
      those identifiers.
      
      On the other hand, trigger names are case sensitive on some platforms,
      and case insensitive on others. 'lower_case_table_names' does not affect
      the behaviour of trigger names either.
      
      The bug was that SHOW statements did case sensitive comparison
      for stored procedure / stored function / event names.
      
      Fix:
      Modified the code so that comparison in case insensitive for routines 
      and events for "SHOW" operation.
      
      As part of this commit, only fixing the test failures due to the actual code fix.
      f3d5127f
    • Sunny Bains's avatar
      Merge from mysql-5.0 · 83a5a20d
      Sunny Bains authored
      83a5a20d
    • Sunny Bains's avatar
      Bug# 13847885 - PURGING STALLS WHEN PURGE_SYS->N_PAGES_HANDLED OVERFLOWS · 65126ffa
      Sunny Bains authored
      Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit
      to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the
      counters can overflow in ~3.5 months, if they are 32 bit.
      
      Approved by Jimmy Yang over IM.
      65126ffa
  6. 27 Mar, 2012 2 commits
  7. 21 Mar, 2012 1 commit
  8. 20 Mar, 2012 2 commits
  9. 16 Mar, 2012 1 commit
  10. 15 Mar, 2012 3 commits
    • Inaam Rana's avatar
      Bug#13825266 RACE IN LOCK_VALIDATE() WHEN ACCESSING PAGES DIRECTLY · 00231470
      Inaam Rana authored
      FROM BUFFER POOL
      
      rb://975
      approved by: Marko Makela
      
      There is a race in lock_validate() where we try to access a page
      without ensuring that the tablespace stays valid during the operation
      i.e.: it is not deleted. This patch tries to fix that by using an
      existing flag (the flag is renamed to make it's name more generic
      in line with it's new use).
      00231470
    • Inaam Rana's avatar
      Bug#13851171 STRING OVERFLOW IN INNODB CODE FOUND BY STATIC ANALYSIS · 04c96834
      Inaam Rana authored
      rb://976
      approved by: Marko Makela
      
      Add an assertion to ensure that string overflow is not happening.
      Pointed by Coverity analysis.
      04c96834
    • Inaam Rana's avatar
      Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES · a8217b7c
      Inaam Rana authored
      IN OS_THREAD_EQ
      
      rb://977
      approved by: Marko Makela
      
      rw_lock::writer_thread field contains the thread id of current x-holder
      or wait-x thread. This field is un-initialized at lock creation and is
      written to for the first time when an attempt is made to x-lock.
      
      Current code considers ::writer_thread as valid memory region only when
      the lock is held in x-mode (or there is an x-waiter). This is an
      overkill and it generates valgrind warnings.
      
      The fix is to consider ::writer_thread as valid memory region once it
      has been written to.
      
      Reasoning:
      ==========
      The ::writer_thread can be safely considered valid because:
      
      * We only ever do comparison with current calling threads id.
      * We only ever do comparison when ::recursive flag is set
      * We always unset ::recursive flag in x-unlock
      * Same thread cannot be unlocking and attempting to lock at the same
      time
      * thread_id recycling is not an issue because before an id is recycled
      the thread must leave innodb meaning it must release all locks meaning
      it must unset ::recursive flag.
      a8217b7c
  11. 12 Mar, 2012 5 commits
    • Luis Soares's avatar
      BUG#12400313 · 7f84e70b
      Luis Soares authored
      Adding missing sync_slave_with_master to the test case.
      7f84e70b
    • Luis Soares's avatar
      Automerge merge with latest mysql-5.1. · a68e3d26
      Luis Soares authored
      a68e3d26
    • Luis Soares's avatar
      BUG#12400313 · 9eedf9b4
      Luis Soares authored
      Hardening the test case:
        - including a diff_tables at the end.
        - increasing the tolerance on the relay limit size.
      9eedf9b4
    • Luis Soares's avatar
      BUG#12400313 · 28e71956
      Luis Soares authored
      Automerge with mysql-5.1.
      28e71956
    • Luis Soares's avatar
      BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES · 4a6c4d86
      Luis Soares authored
      BUG#64503: mysql frequently ignores --relay-log-space-limit
      
      When the SQL thread goes to sleep, waiting for more events, it sets
      the flag ignore_log_space_limit to true. This gives the IO thread a
      chance to queue some more events and ultimately the SQL thread will be
      able to purge the log once it is rotated. By then the SQL thread
      resets the ignore_log_space_limit to false. However, between the time
      the SQL thread has set the ignore flag and the time it resets it, the
      IO thread will be queuing events in the relay log, possibly going way
      over the limit.
      
      This patch makes the IO and SQL thread to synchronize when they reach
      the space limit and only ask for one event at a time. Thus the SQL
      thread sets ignore_log_space_limit flag and the IO thread resets it to
      false everytime it processes one more event. In addition, everytime
      the SQL thread processes the next event, and the limit has been
      reached, it checks if the IO thread should rotate. If it should, it
      instructs the IO thread to rotate, giving the SQL thread a chance to
      purge the logs (freeing space). Finally, this patch removes the
      resetting of the ignore_log_space_limit flag from purge_first_log,
      because this is now reset by the IO thread every time it processes the
      next event when the limit has been reached.
      
      If the SQL thread is in a transaction, it cannot purge so, there is no
      point in asking the IO thread to rotate. The only thing it can do is
      to ask for more events until the transaction is over (then it can ask
      the IO to rotate and purge the log right away). Otherwise, there would
      be a deadlock (SQL would not be able to purge and IO thread would not
      be able to queue events so that the SQL would finish the transaction).
      4a6c4d86
  12. 09 Mar, 2012 1 commit
  13. 08 Mar, 2012 2 commits
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD · c5511bdf
      Marko Mäkelä authored
      This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the
      code probably was even more severely broken.)
      
      btr_pcur_restore_position(): When cursor restoration fails, before
      invoking btr_pcur_store_position() move to the previous or next record
      unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user
      record.
      
      This bug can cause skipped records when btr_pcur_store_position() is
      called on the last record of a page. A symptom would be record count
      mismatch in CHECK TABLE, or failure to find a record to delete-mark or
      update or purge. The following operations should be affected by the
      bug:
      
      * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE,
        (almost anything else than INSERT)
      
      * foreign key CASCADE operations
      
      * row_merge_read_clustered_index(): index creation (since MySQL 5.1
        InnoDB Plugin)
      
      * multi-threaded purge (after MySQL 5.5): not sure, but it might fail
        to purge some records
      
      Not all callers of btr_pcur_restore_position() should be affected.
      Anything that asserts or checks that restoration succeeds is
      unaffected. For example, cursor restoration on the change buffer tree
      should always succeed, because access is being protected by additional
      latches. Likewise, rollback, or any code accesses data dictionary
      tables while holding dict_sys->mutex should be safe.
      
      rb:967 approved by Jimmy Yang
      c5511bdf
  14. 06 Mar, 2012 1 commit
  15. 02 Mar, 2012 2 commits
  16. 29 Feb, 2012 3 commits
    • Mattias Jonsson's avatar
      merge into mysql-5.1 · 937ee6b7
      Mattias Jonsson authored
      937ee6b7
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · cf2f9780
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      
      cf2f9780
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · c22c9270
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      
      
      
      mysql-test/r/sql_mode.result:
        Added test case for Bug#12601974.
      mysql-test/suite/binlog/r/binlog_sql_mode.result:
        Appended result of test cases added for Bug#12601974.
      mysql-test/suite/binlog/t/binlog_sql_mode.test:
        Added test case for Bug#12601974.
      mysql-test/t/sql_mode.test:
        Appended result of test cases added for Bug#12601974.
      c22c9270
  17. 28 Feb, 2012 5 commits
  18. 27 Feb, 2012 1 commit
  19. 24 Feb, 2012 1 commit
    • Chaithra Gopalareddy's avatar
      Bug#13012483:EXPLAIN EXTENDED, PREPARED STATEMENT, CRASH IN · 6a0d03fc
      Chaithra Gopalareddy authored
      CHECK_SIMPLE_EQUALITY
      
      PROBLEM:
      Crash in "check_simple_equality" when using a subquery with "IN" and
      "ALL" in prepare.
      
      ANALYSIS:
      Crash can be reproduced using a simplified query like this one:
      prepare s from "select 1 from g1 where 1 < all (
                      select @:=(1 in (select 1 from g1)) from g1)";
      
      This bug is currently present only on 5.5.and 5.1. Its fixed as part
      of work log(#1110) in 5.6. We are taking one change to fix this
      in 5.5 and 5.1.
      
      Problem seems to be present because we are trying to evaluate "is_null"
      on an argument which is part of a subquery
      (In Item_is_not_null_test::update_used_tables()).
      But the condition to evaluate is only when we do not have a sub query
      present, which means to say that "with_subselect" is not set.
      With respect to the above query, we create an object of type
      "Item_in_optimizer" which by definition is always associated with a
      subquery. While in 5.6 we set "with_subselect" to true for
      "Item_in_optimizer" object, we do not do the same in 5.5. This results in
      the evaluation for "is_null" resulting in a coredump.
      So, we are now setting "with_subselect" to true for "Item_in_optimizer"
      in 5.1 and 5.5.
      
      
      mysql-test/r/func_in.result:
        Result file changes for the test case added
      mysql-test/t/func_in.test:
        Test case added for Bug#13012483
      sql/item_cmpfunc.h:
        Changed Item_in_optimizer::Item_in_optimizer( ) to set "with_subselect"
        to true
      6a0d03fc
  20. 21 Feb, 2012 3 commits