1. 29 Jul, 2013 3 commits
    • Aditya A's avatar
      Bug#13417564 SKIP SLEEP IN SRV_MASTER_THREAD WHEN · a1fd9426
      Aditya A authored
                   SHUTDOWN IS IN PROGRESS 
      
      [ Null Merge from mysql-5.1]
      a1fd9426
    • Aditya A's avatar
      Bug#13417564 SKIP SLEEP IN SRV_MASTER_THREAD WHEN · f7940e40
      Aditya A authored
                   SHUTDOWN IS IN PROGRESS 
      
      PROBLEM
      -------
       In the background thread srv_master_thread() we have a 
       a one second delay loop which will continuously monitor
       server activity .If the server is inactive (with out any
       user activity) or in a shutdown state we do some background
       activity like flushing the changes.In the current code
       we are not checking if server is in shutdown state before
       sleeping for one second.
      
      FIX
      ---
      If server is in shutdown state ,then dont go to one second
      sleep. 
      f7940e40
    • Aditya A's avatar
      Bug #11766851 QUERYING I_S.PARTITIONS CHANGES THE CARDINALITY OF THE · 900c5714
      Aditya A authored
                    PARTITIONS.
      
      ANALYSIS
      --------
      Whenever we query I_S.partitions,
      ha_partition::get_dynamic_partition_info()
      is called which resets the cardinality 
      according to the number of rows in last
      partition.
      
      Fix
      ---
      When we call get_dynamic_partition_info() 
      avoid passing the flag HA_STATUS_CONST
      to info() since HA_STATUS_CONST should 
      ideally not be called for per partition.
      
      [Approved by mattiasj rb#2830 ]
      900c5714
  2. 27 Jul, 2013 1 commit
    • Venkatesh Duggirala's avatar
      BUG#16290902 DROP TEMP TABLE IF EXISTS CAN CAUSE POINT · bf2c49d3
      Venkatesh Duggirala authored
      IN TIME RECOVERY FAILURE ON SLAVES
      
      Problem:
      DROP TEMP TABLE IF EXISTS commands can cause point
      in time recovery (re-applying binlog) failures.
      
      Analyses:
      In RBR, 'DROP TEMPORARY TABLE' commands are
      always binlogged by adding 'IF EXISTS' clauses.
      Also, the slave SQL thread will not check replicate.* filter
      rules for "DROP TEMPORARY TABLE IF EXISTS" queries.
      If log-slave-updates is enabled on slave, these queries
      will be binlogged in the format of "USE `db`;
      DROP TEMPORARY TABLE IF EXISTS `t1`;" irrespective
      of filtering rules and irrespective of the `db` existence.
      When users try to recover slave from it's own binlog,
      use `db` command might fail if `db` is not present on slave.
      
      Fix:
      At the time of writing the 'DROP TEMPORARY TABLE
      IF EXISTS' query into the binlog, 'use `db`' will not be
      present and the table name in the query will be a fully
      qualified table name.
      Eg:
      'USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;'
      will be logged as
      'DROP TEMPORARY TABLE IF EXISTS `db`.`t1`;'.
      bf2c49d3
  3. 25 Jul, 2013 2 commits
  4. 24 Jul, 2013 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#16865959 - PLEASE BACKPORT BUG 14749800. · 0ae219cd
      Praveenkumar Hulakund authored
      Since log_throttle is not available in 5.5. Logging of
      error message for failure of thread to create new connection
      in "create_thread_to_handle_connection" is not backported.
      
      Since, function "my_plugin_log_message" is not available in 
      5.5 version and since there is incompatibility between
      sql_print_XXX function compiled with g++ and alog files with
      gcc to use sql_print_error, changes related to audit log
      plugin is not backported.
      0ae219cd
  5. 23 Jul, 2013 5 commits
  6. 18 Jul, 2013 2 commits
    • Nisha Gopalakrishnan's avatar
      BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING · 70cb66b9
      Nisha Gopalakrishnan authored
                    TO DUMP DATA FROM MYSQL-5.6 
      
      Merge from mysql-5.1 to mysql-5.5.
      70cb66b9
    • Nisha Gopalakrishnan's avatar
      BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING · 5d74d07b
      Nisha Gopalakrishnan authored
                    TO DUMP DATA FROM MYSQL-5.6
      
      Analysis
      --------
      Dumping mysql-5.6 data using mysql-5.1/mysql-5.5 'myqldump'
      utility fails with a syntax error.
      
      Server system variable 'sql_quote_show_create' which quotes the
      identifiers is set in the mysqldump utility. The mysldump utility
      of mysql-5.1/mysql-5.5 uses deprecated syntax 'SET OPTION' to set
      the 'sql_quote_show_create' option. The support for the syntax is
      removed in mysql-5.6. Hence syntax error is reported while taking
      the dump.
      
      Fix:
      ---
      Changed the 'mysqldump' code to use the syntax
      'SET SQL_QUOTE_SHOW_CREATE' to set the 'sql_quote_show_create'
      option. That syntax is supported on mysql-5.1, mysql-5.5 and
      mysql-5.6.
      
      NOTE: I have not added an mtr test case since it is difficult
      to simulate the condition. Also the syntax may not be further
      simplified in the future.
      5d74d07b
  7. 17 Jul, 2013 2 commits
  8. 10 Jul, 2013 2 commits
  9. 09 Jul, 2013 2 commits
  10. 08 Jul, 2013 1 commit
  11. 05 Jul, 2013 1 commit
    • Aditya A's avatar
      Bug#17033706 SINCE 5.5.32 & 5.6.12, INNODB CANT START WITH OWN · 37d9d243
      Aditya A authored
                   MULTI-FILE TABLESPACE
      
      ANALYSIS
      --------
      
      When a tablespace has multiple data files, InnoDB fails to 
      open the tablespace.  This is because for each ibd file, 
      the first page is checked.But the first page of all ibd file
      need not be the first page of the tablespace.  Only the first
      page of the tablespace contains the tablespace header. When 
      we check the first page of an ibd file that is not the first
      page of the tablespace, then the "tablespace flags" is not
      really available.This was wrongly used to check if a page is
      corrupt or not.
      
      FIX
      ---
      Use the tablespace flags only if the page number is 0 
      in a tablespace.  
      
      [Approved by Inaam rb#2836 ]
      37d9d243
  12. 04 Jul, 2013 1 commit
    • Venkata Sidagam's avatar
      Bug #16567381 DATETIME FIELD COMPARISONS DO NOT WORK PROPERLY · 18d34a47
      Venkata Sidagam authored
                      WITH UTF8_UNICODE_CI COLLATION
      Problem Description:
      When comparing datetime values with strings, the utf8_unicode_ci collation 
      prevents correct comparisons. Consider the below set of queries, it is not 
      showing any results on a table which has tuples that satisfies the query. 
      But for collation utf8_general_ci it shows one tuple.
      set names utf8 collate utf8_unicode_ci;;
      select * from lang where dt='1979-12-09';
      
      Analysis:
      The comparison function is not chosen in case of collation utf8_unicode_ci.
      In agg_item_set_converter() because the collation state is having 
      "MY_CS_NONASCII" for collation type "utf8_unicode_ci". The conversion 
      of the collation is happening for the date field. And because of that 
      it is unable to pickup proper compare function(i.e CMP_DATE_WITH_STR).
      
      Actually the bug is accidentally introduced by the WL#3759 in 5.5. 
      And in 5.6 it is been fixed by the WL#3664.
      
      Fix:
      I have backported the changes from the file strings/ctype-uca.c which 
      are related to "utf8" introduced by the WL#3664.
      This change helps in choosing the correct comparison function for all 
      the collations of utf8 charset.
      18d34a47
  13. 01 Jul, 2013 3 commits
  14. 28 Jun, 2013 2 commits
  15. 27 Jun, 2013 2 commits
  16. 26 Jun, 2013 3 commits
  17. 25 Jun, 2013 1 commit
  18. 24 Jun, 2013 3 commits
    • mysql-builder@oracle.com's avatar
      No commit message · b31a7ebe
      mysql-builder@oracle.com authored
      No commit message
      b31a7ebe
    • Sujatha Sivakumar's avatar
      Bug#16753869:INCORRECT TRUNCATION OF LONG SET EXPRESSION IN · 318077c4
      Sujatha Sivakumar authored
      LOAD DATA CAN CAUSE SQL INJECTION
      
      Problem:
      =======
      A long SET expression in LOAD DATA is incorrectly truncated
      when written to the binary log.
      
      Analysis:
      ========
      LOAD DATA statements are reconstructed once again before
      they are written to the binary log. When SET clauses are
      specified as part of LOAD DATA statement, these SET clause
      user command strings need to be stored as it is inorder to
      reconstruct the original user command.  At present these
      strings are stored as part of SET clause item tree's
      top most Item node's name itself which is incorrect. As an
      Item::name can be of MAX_ALIAS_NAME (256) size. Hence the
      name will get truncated to "255".
      
      Because of this the rewritten LOAD DATA statement will be
      terminated incorrectly.  When this statment is read back by
      the mysqlbinlog tool it reads a starting single quote and
      continuos to read till it finds an ending quote. Hence any
      statement written post ending quote will be considered as
      a new statement.
      
      Fix:
      ===
      As name field has length restriction the string value
      should not be stored in Item::name.  A new String list is
      maintained to store the SET expression values and this list
      is read during reconstrution.
      318077c4
    • mysql-builder@oracle.com's avatar
      No commit message · a326f974
      mysql-builder@oracle.com authored
      No commit message
      a326f974
  19. 21 Jun, 2013 1 commit
    • Tor Didriksen's avatar
      Bug#16945503 ADDRESSSANITIZER BUG IN SYS_VARS · 966e1a42
      Tor Didriksen authored
      Sys_var_keycache inherits from some variant of Sys_var_integer
      
      Instances of Sys_var_keycache are initialized using the KEYCACHE_VAR macro,
      which takes an offset within st_key_cache.
      However, the Sys_var_integer CTOR treats the offset as if it was within
      global_system_variables (hidden within some layers of macros and fuction
      pointers)
      
      The result is that we write arbitrary data to arbitrary locations in memory.
      This all happens during static initialization of global objects,
      i.e. before we have even entered the main() function.
      
      
      Bug#12325449 TYPO IN CMAKE/DTRACE.CMAKE
      Fix typo in dtrace.cmake
      966e1a42
  20. 19 Jun, 2013 2 commits