1. 23 Jul, 2013 2 commits
  2. 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
  3. 17 Jul, 2013 2 commits
  4. 10 Jul, 2013 2 commits
  5. 09 Jul, 2013 2 commits
  6. 08 Jul, 2013 1 commit
  7. 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
  8. 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
  9. 01 Jul, 2013 3 commits
  10. 28 Jun, 2013 2 commits
  11. 27 Jun, 2013 2 commits
  12. 26 Jun, 2013 3 commits
  13. 25 Jun, 2013 1 commit
  14. 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
  15. 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
  16. 19 Jun, 2013 2 commits
  17. 18 Jun, 2013 4 commits
  18. 17 Jun, 2013 1 commit
  19. 14 Jun, 2013 5 commits