1. 10 Jul, 2013 1 commit
    • Annamalai Gurusami's avatar
      Bug #14017206 WITH CONSISTENT SNAPSHOT DOES NOT WORK WITH ISOLATION LEVEL · 64c58c13
      Annamalai Gurusami authored
      SERIALIZABLE
      
      Problem:
      
      The documentation claims that WITH CONSISTENT SNAPSHOT will work for both
      REPEATABLE READ and SERIALIZABLE isolation levels.  But it will work only
      for REPEATABLE READ isolation level.  Also, the clause WITH CONSISTENT
      SNAPSHOT is silently ignored when it is not applicable to the given isolation
      level.  
      
      Solution:
      
      Generate a warning when the clause WITH CONSISTENT SNAPSHOT is ignored.
      
      rb#2797 approved by Kevin.
      
      Note: Support team wanted to push this to 5.5+.
      64c58c13
  2. 09 Jul, 2013 2 commits
  3. 08 Jul, 2013 1 commit
  4. 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
  5. 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
  6. 01 Jul, 2013 3 commits
  7. 28 Jun, 2013 2 commits
  8. 27 Jun, 2013 2 commits
  9. 26 Jun, 2013 3 commits
  10. 25 Jun, 2013 1 commit
  11. 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
  12. 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
  13. 19 Jun, 2013 2 commits
  14. 18 Jun, 2013 4 commits
  15. 17 Jun, 2013 1 commit
  16. 14 Jun, 2013 7 commits
  17. 13 Jun, 2013 1 commit
    • Annamalai Gurusami's avatar
      Bug #16417635 INNODB FAILS TO MERGE UNDER-FILLED PAGES DEPENDING · 9f3ceb97
      Annamalai Gurusami authored
      ON DELETION ORDER
      
      Problem:
      
      When a InnoDB index page is under-filled, we will merge it with either
      the left sibling node or the right sibling node.  But this checking is
      incorrect.  When the left sibling node is available, even if merging
      is not possible with left sibling node, we do not check for the 
      possibility of merging with the right sibling node.  
      
      Solution:
      
      If left sibling node is available, and merging with left sibling node
      is not possible, then check if merge with right sibling node is
      possible.
      
      rb#2506 approved by jimmy & ima.
      9f3ceb97
  18. 12 Jun, 2013 2 commits
    • Sivert Sorumgard's avatar
      Bug #14227431: CHARACTER SET MISMATCH WHEN ALTERING FOREIGN KEYS · e7d8f19b
      Sivert Sorumgard authored
      CAN LEAD TO MISSING TABLES
      
      Overview
      --------
      If the FOREIGN_KEY_CHECKS system variable is set to 0, it is
      possible to break a foreign key constraint by changing the type
      or character set of the foreign key column, or by dropping the
      foreign key index (without carrying out corresponding changes on
      another table in the relationship).
      
      If we subsequently set FOREIGN_KEY_CHECKS to 1 and execute ALTER
      TABLE involving the COPY algorithm on such a table, the following
      happens:
      
      1) If ALTER TABLE does not contain a RENAME clause, the attempt 
         to install the new version of the table instead of the old one
         will fail due to the fact that the inconsistency will be 
         detected. An attempt to revert the partially executed alter 
         table operation by restoring the old table definition will 
         fail as well due to FOREIGN_KEY_CHECKS == 1. As a result, the 
         table being altered will be lost.
      2) If ALTER TABLE contains the RENAME clause, the inconsistency 
         will not be detected (most probably due to other bugs). But if
         an attempt to install the new version of the table fails (for 
         example, due to a failure when updating triggers associated 
         with the table), reverting the partially executed alter table 
         by restoring the old table definition will fail too. So the 
         table being altered might be lost as well.
      
      
      Suggested fix
      -------------
      The suggested fix is to temporarily unset the option bit
      representing FOREIGN_KEY_CHECKS when the old table definition is
      restored while reverting the partially executed operation.
      e7d8f19b
    • mysql-builder@oracle.com's avatar
      No commit message · c32bdeeb
      mysql-builder@oracle.com authored
      No commit message
      c32bdeeb
  19. 10 Jun, 2013 2 commits