1. 14 Jun, 2013 2 commits
    • Aditya A's avatar
      Bug#13548704 ALGORITHM USED FOR DROPPING PARTITIONED TABLE CAN LEAD · 3373a7ed
      Aditya A authored
                   TO INCONSISTENCY 
      [Merge from 5.1]
      3373a7ed
    • Aditya A's avatar
      Bug#13548704 ALGORITHM USED FOR DROPPING PARTITIONED TABLE CAN LEAD · 5f3c0a45
      Aditya A authored
                   TO INCONSISTENCY 
      
      PROBLEM
      --------
      When we drop a partitoned table , we first gather the
      information about partitions in the table from the 
      table_name.par file and store it in an internal data 
      structure.Then we delete this file and the data in 
      the table. If the server crashes  after deleting the
      file,then after recovering we cannot access the table
      .Even we cannot drop the table ,because drop algorithm
      requires par file to read the partition information.
      
      
      FIX
      ---
      1. We move the part of deleting par file after deleting 
         all the table data from the storage egine.
      2. During drop operation if we detect that the par 
         file is missing then we delete the .frm file,since 
         there is no way of recovering without par file.
        
      [Approved by Mattias rb#2576 ]   
      5f3c0a45
  2. 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
  3. 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
  4. 10 Jun, 2013 3 commits
  5. 07 Jun, 2013 2 commits
  6. 06 Jun, 2013 1 commit
  7. 05 Jun, 2013 1 commit
  8. 04 Jun, 2013 1 commit
  9. 03 Jun, 2013 1 commit
  10. 29 May, 2013 1 commit
  11. 24 May, 2013 4 commits
    • Maitrayi Sabaratnam's avatar
      4371 Maitrayi Sabaratnam 2013-05-23 · 94a708f5
      Maitrayi Sabaratnam authored
            Bug#13116514 - CREATE LOGFILE GROUP INITIAL_SIZE & UNDO_BUFFER_SIZE FAILS
            
            Fixing parser to accept the syntax: to give a size with suffix 'M', eg. undo_buffer_size=10M (M for mega bytes), in 'create logfile group' command.
      94a708f5
    • Marko Mäkelä's avatar
      Bug#16859867 INNODB_BUG14529666 FAILS SPORADICALLY IN VALGRIND · 7c659589
      Marko Mäkelä authored
      i_s_innodb_buffer_page_get_info(): Do not read the buffer block frame
      contents of read-fixed blocks, because it may be invalid or
      uninitialized. When we are going to decompress or read a block, we
      will put it into buf_pool->page_hash and buf_pool->LRU, read-fix the
      block and release the mutexes for the duration of the reading or
      decompression.
      
      rb#2500 approved by Jimmy Yang
      7c659589
    • Venkatesh Duggirala's avatar
      Bug#16765278 DELETE SQL_LOAD_MB* FILE (TEMP FILE) CREATED · 090bc57b
      Venkatesh Duggirala authored
      BY BINLOG_KILLED_SIMULATE.TEST
      Merging fix from mysql-5.1
      090bc57b
    • Venkatesh Duggirala's avatar
      Bug#16765278 DELETE SQL_LOAD_MB* FILE (TEMP FILE) CREATED · 8ee7751f
      Venkatesh Duggirala authored
      BY BINLOG_KILLED_SIMULATE.TEST
            
      'mysqbinlog' tool creates a temporary file while 
      preparing LOAD DATA QUERY. These files needs to be deleted
      at the end of the test script otherwise these files are
      left out in the daily-run machines, causing
      "no space on device issues"
            
      Fix: 
      Delete them at the end of these test scripts
      1) execute mysqlbinlog with --local-load option to
      create these files in a specified tmpdir
      2) delete the tmpdir at the end of the test script
      8ee7751f
  12. 23 May, 2013 3 commits
    • Chaithra Gopalareddy's avatar
      Null merge from 5.1 to 5.5 · 38751bdd
      Chaithra Gopalareddy authored
      38751bdd
    • Chaithra Gopalareddy's avatar
      Bug #16119355: PREPARED STATEMENT: READ OF FREED MEMORY WITH · 5bf9b7d0
      Chaithra Gopalareddy authored
                                       STRING CONVERSION FUNCTIONS
                  
      Problem:
      While executing the prepared statement, user variable is
      set to memory which would be freed at the end of
      execution.
      If the statement is executed again, valgrind throws
      error when accessing this pointer.
                        
      Analysis:
                      
      1. First time when Item_func_set_user_var::check is called,
         memory is allocated for "value" to store the result.
         (In the call to copy_if_not_alloced).
      2. While sending the result, Item_func_set_user_var::check
         is called again. But, this time, its called with
         "use_result_field" set to true. 
         As a result, we call result_field->val_str(&value).
      3. Here memory allocated for "value" gets freed. And "value"
         gets set to "result_field", with "str_length" being that of
         result_field's.
      4. In the call to JOIN::cleanup, result_field's memory gets
         freed as this is allocated in a chunk as part of the
         temporary table which is needed to execute the query.
      5. Next time, when execute of the same statement is called,
         "value" will be set to memory which is already freed.
         Valgrind error occurs as "str_length" is positive 
         (set at Step 3)
                        
      Note that user variables list is stored as part of the Lex object
      in set_var_list. Hence the persistance across executions.
                  
      Solution:
      Patch for Bug#11764371 fixed in mysql-5.6+ fixes this problem 
      as well.So backporting the same.
                  
      In the solution for Bug#11764371, we create another object of 
      user_var and repoint it to temp_table's field. As a result while 
      deleting the alloced buffer in Step 3, since the cloned object 
      does not own the buffer, deletion will not happen.
      So at step 5 when we execute the statement second time, the 
      original object will be used and since deletion did not happen 
      valgrind will not complain about dangling pointer.
      5bf9b7d0
    • Chaithra Gopalareddy's avatar
      Merge from 5.5 to 5.6 · 34a02014
      Chaithra Gopalareddy authored
      34a02014
  13. 22 May, 2013 1 commit
  14. 20 May, 2013 1 commit
  15. 19 May, 2013 1 commit
    • Ashish Agarwal's avatar
      Bug#16194302: SUPPORT FOR FLOATING-POINT SYSTEM VARIABLES · 918b6a3e
      Ashish Agarwal authored
                    USING THE PLUGIN INTERFACE.
      
      ISSUE: No support for floating-point plugin
             system variables.
      
      SOLUTION: Allowing plugins to define and expose floating-point
                system variables of type double. MYSQL_SYSVAR_DOUBLE
                and MYSQL_THDVAR_DOUBLE are added.
      
      ISSUE: Fractional part of the def, min, max values of system
             variables are ignored.
      
      SOLUTION: Adding functions that are used to store the raw
                representation of a double in the raw bits of unsigned
                longlong in a way that the binary representation
                remains the same.
      918b6a3e
  16. 18 May, 2013 1 commit
    • Annamalai Gurusami's avatar
      Bug #12762377 FOREIGN KEYS NOT CONSTRUCTED WHEN APOSTROPHES ARE · 00cf6212
      Annamalai Gurusami authored
      ESCAPED WITH BACKSLASH
      
      Problem:
      
      When the CREATE TABLE statement used COMMENTS with escape sequences like
      'foo\'s', InnoDB did not parse is correctly when trying to extract the
      foreign key information.  Because of this, the foreign keys specified
      in the CREATE TABLE statement were not created.
      
      Solution:
      
      Make the InnoDB internal parser aware of escape sequences. 
      
      rb#2457 approved by Kevin.
      00cf6212
  17. 17 May, 2013 2 commits
    • Venkatesh Duggirala's avatar
      Bug#14236170 MYSQLDUMP 5.5.25 CLIENT FAILS TO DUMP · 0dd7348f
      Venkatesh Duggirala authored
      MYSQL DB FROM REMOTE 5.0.96 SERVER
      
      Problem: mysqldump tool assumes the existence of
      general_log and slow_log tables in the server.
      If mysqldump tool executes on a old server where
      there are no log tables like these, mysqldump tool
      fails.
      
      Analysis: general_log and slow_log tables are added
      in the ignore-table list as part of bug-26121 fix
      causes bug-45740 (MYSQLDUMP DOESN'T DUMP GENERAL_LOG
      AND SLOW_QUERY CAUSES RESTORE PROBLEM). As part of
      the bug-45740 fix, mysqldump tool adds create table
      queries for these two tables. But the fix assumes
      that on all the servers, general_log and slow_log
      will be there. If the new mysqldump tool is executed
      against a old server where there are no general_log
      and slow_log, the mysqldump tool fails with an error
      that 'there is no general_log table'.
      
      Fix: When mysqldump tool is trying to retrieve general_log
      and slow_log table structures, first the tool should
      check their existence of these tables in the server
      instead of trying to dump it blindly.
      0dd7348f
    • mysql-builder@oracle.com's avatar
      No commit message · b674eabc
      mysql-builder@oracle.com authored
      No commit message
      b674eabc
  18. 16 May, 2013 12 commits