1. 29 Jul, 2013 1 commit
    • Aditya A's avatar
      Bug #11766851 QUERYING I_S.PARTITIONS CHANGES THE CARDINALITY OF THE · 21b42b81
      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 ]
      
      21b42b81
  2. 27 Jul, 2013 1 commit
    • Venkatesh Duggirala's avatar
      BUG#16290902 DROP TEMP TABLE IF EXISTS CAN CAUSE POINT · eb152f86
      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`;'.
      eb152f86
  3. 25 Jul, 2013 2 commits
  4. 24 Jul, 2013 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#16865959 - PLEASE BACKPORT BUG 14749800. · 03940a7b
      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.
      03940a7b
  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 · 09db23ae
      Nisha Gopalakrishnan authored
                    TO DUMP DATA FROM MYSQL-5.6 
      
      Merge from mysql-5.1 to mysql-5.5.
      09db23ae
    • Nisha Gopalakrishnan's avatar
      BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING · 30a37ca9
      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.
      30a37ca9
  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 · eee10f38
      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 ]
      eee10f38
  12. 04 Jul, 2013 1 commit
    • Venkata Sidagam's avatar
      Bug #16567381 DATETIME FIELD COMPARISONS DO NOT WORK PROPERLY · ae59c577
      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.
      ae59c577
  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
    • unknown's avatar
      No commit message · 87015f4c
      unknown authored
      No commit message
      87015f4c
    • Sujatha Sivakumar's avatar
      Bug#16753869:INCORRECT TRUNCATION OF LONG SET EXPRESSION IN · ce29ca8b
      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.
      
      sql/sql_lex.cc:
        Clear the load data set string list during each query 
        execution.
      sql/sql_lex.h:
        Added a new String list to store the load data operation's
        SET clause user command strings.
      sql/sql_load.cc:
        Read the SET clause user command strings from load data
        set string list.
      sql/sql_yacc.yy:
        Store the SET caluse user command string as part of load
        data set string list.
      ce29ca8b
    • unknown's avatar
      No commit message · 99c7d1f1
      unknown authored
      No commit message
      99c7d1f1
  19. 21 Jun, 2013 1 commit
    • Tor Didriksen's avatar
      Bug#16945503 ADDRESSSANITIZER BUG IN SYS_VARS · 98ed58ca
      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
      98ed58ca
  20. 19 Jun, 2013 2 commits
  21. 18 Jun, 2013 2 commits