1. 23 Apr, 2012 1 commit
    • Andrei Elkin's avatar
      BUG#11754117 · d5925c20
      Andrei Elkin authored
      rpl_auto_increment_bug45679.test is refined due to not fixed in 5.1 Bug11749859-39934.
      d5925c20
  2. 20 Apr, 2012 1 commit
    • Andrei Elkin's avatar
      BUG#11754117 incorrect logging of INSERT into auto-increment · f3509d1d
      Andrei Elkin authored
      BUG#11761686 insert_id event is not filtered.
        
      Two issues are covered.
        
      INSERT into autoincrement field which is not the first part in the composed primary key 
      is unsafe by autoincrement logging design. The case is specific to MyISAM engine
      because Innodb does not allow such table definition.
        
      However no warnings and row-format logging in the MIXED mode was done, and
      that is fixed.
        
      Int-, Rand-, User-var log-events were not filtered along with their parent
      query that made possible them to screw up execution context of the following
      query.
        
      Fixed with deferring their execution until the parent query.
      
      ******
      Bug#11754117 
      
      Post review fixes.
      f3509d1d
  3. 19 Apr, 2012 1 commit
    • Mayank Prasad's avatar
      BUG#12427262 : 60961: SHOW TABLES VERY SLOW WHEN NOT IN SYSTEM DISK CACHE · 5203d9bb
      Mayank Prasad authored
      Reason:
       This is a regression happened because of changes done in code refactoring 
       in 5.1 from 5.0.
      
      Issue: 
       While doing "Show tables" lex->verbose was being checked to avoid opening
       FRM files to get table type. In case of "Show full table", lex->verbose
       is true to indicate table type is required. In 5.0, this check was
       present which got missing in >=5.5.
      
      Fix:
       Added the required check to avoid opening FRM files unnecessarily in case
       of "Show tables".
      5203d9bb
  4. 18 Apr, 2012 4 commits
    • Tor Didriksen's avatar
      adb352ca
    • Tor Didriksen's avatar
      Backport 5.5=>5.1 Patch for Bug#13805127: · d612986b
      Tor Didriksen authored
      Stored program cache produces wrong result in same THD.
      d612986b
    • Nuno Carvalho's avatar
      WL#6236: Allow SHOW MASTER LOGS and SHOW BINARY LOGS with REPLICATION CLIENT · a9a7e6ea
      Nuno Carvalho authored
      Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER
      privilege. Monitoring tools (such as MEM) often want to check this 
      output - for instance MEM generates the SUM of the sizes of the logs 
      reported here, and puts that in the Replication overview within the MEM
      Dashboard.
      However, because of the SUPER requirement, these tools often have an 
      account that holds open the connection whilst monitoring, and can lock
      out administrators when the server gets overloaded and reaches
      max_connections - there is already another SUPER privileged account
      connected, the "monitor". 
      
      As SHOW MASTER STATUS, and all other replication related statements,
      return with either REPLICATION CLIENT or SUPER privileges, this worklog 
      is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this
      as well, and allow both of these commands with either SUPER or 
      REPLICATION CLIENT. 
      This allows monitoring tools to not require a SUPER privilege any more,
      so is safer in overloaded situations, as well as being more secure, as 
      lighter privileges can be given to users of such tools or scripts.
      a9a7e6ea
    • Chaithra Gopalareddy's avatar
      Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER · 81058259
      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.
      81058259
  5. 17 Apr, 2012 1 commit
  6. 09 Apr, 2012 1 commit
  7. 06 Apr, 2012 1 commit
    • Mayank Prasad's avatar
      BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD · fccf6698
      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.
      fccf6698
  8. 28 Mar, 2012 3 commits
    • Praveenkumar Hulakund's avatar
      Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVE · 19c375c9
      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.
      19c375c9
    • Sunny Bains's avatar
      Merge from mysql-5.0 · 899e600b
      Sunny Bains authored
      899e600b
    • Sunny Bains's avatar
      Bug# 13847885 - PURGING STALLS WHEN PURGE_SYS->N_PAGES_HANDLED OVERFLOWS · 0ebe1273
      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.
      0ebe1273
  9. 27 Mar, 2012 2 commits
  10. 21 Mar, 2012 1 commit
  11. 20 Mar, 2012 2 commits
  12. 16 Mar, 2012 1 commit
  13. 15 Mar, 2012 3 commits
    • Inaam Rana's avatar
      Bug#13825266 RACE IN LOCK_VALIDATE() WHEN ACCESSING PAGES DIRECTLY · 486e5e5a
      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).
      486e5e5a
    • Inaam Rana's avatar
      Bug#13851171 STRING OVERFLOW IN INNODB CODE FOUND BY STATIC ANALYSIS · 8729b2e5
      Inaam Rana authored
      rb://976
      approved by: Marko Makela
      
      Add an assertion to ensure that string overflow is not happening.
      Pointed by Coverity analysis.
      8729b2e5
    • Inaam Rana's avatar
      Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES · df2da7d7
      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.
      df2da7d7
  14. 12 Mar, 2012 5 commits
    • Luis Soares's avatar
      BUG#12400313 · 975e6708
      Luis Soares authored
      Adding missing sync_slave_with_master to the test case.
      975e6708
    • Luis Soares's avatar
      Automerge merge with latest mysql-5.1. · deb49a26
      Luis Soares authored
      deb49a26
    • Luis Soares's avatar
      BUG#12400313 · ab03c5ba
      Luis Soares authored
      Hardening the test case:
        - including a diff_tables at the end.
        - increasing the tolerance on the relay limit size.
      ab03c5ba
    • Luis Soares's avatar
      BUG#12400313 · c41a6fec
      Luis Soares authored
      Automerge with mysql-5.1.
      c41a6fec
    • Luis Soares's avatar
      BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES · 5360c4e5
      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).
      5360c4e5
  15. 09 Mar, 2012 1 commit
  16. 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 · 76e064e2
      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
      76e064e2
  17. 06 Mar, 2012 1 commit
  18. 02 Mar, 2012 2 commits
  19. 29 Feb, 2012 3 commits
    • Mattias Jonsson's avatar
      merge into mysql-5.1 · bd5f062f
      Mattias Jonsson authored
      bd5f062f
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · 892760d9
      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: )
      892760d9
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · 9af695fb
      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: )
      9af695fb
  20. 28 Feb, 2012 4 commits