1. 16 Feb, 2012 6 commits
  2. 15 Feb, 2012 6 commits
  3. 13 Feb, 2012 2 commits
  4. 10 Feb, 2012 4 commits
  5. 09 Feb, 2012 2 commits
    • Rohit Kalhans's avatar
      Followup patch for bug#11758263. · 17eea529
      Rohit Kalhans authored
      17eea529
    • Rohit Kalhans's avatar
      BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE · 4f7e4c9d
      Rohit Kalhans authored
             
      Problem: Statements that write to tables with auto_increment columns
               based on the selection from another table, may lead to master
               and slave going out of sync, as the order in which the rows
               are retrieved from the table may differ on master and slave.
                  
      Solution: We mark writing to a table with auto_increment table
                based on the rows selected from another table as unsafe. This
                will cause the execution of such statements to throw a warning
                and forces the statement to be logged in ROW if the logging
                format is mixed. 
                  
      Changes:
             1. All the statements that writes to a table with auto_increment 
                column(s) based on the rows fetched from another table, will now
                be unsafe.
             2. CREATE TABLE with SELECT will now be unsafe.
      4f7e4c9d
  6. 08 Feb, 2012 1 commit
  7. 07 Feb, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE · 6df5a61d
      Rohit Kalhans authored
            
            Problem: Statements that write to tables with auto_increment columns
            based on the selection from another table, may lead to master
            and slave going out of sync, as the order in which the rows
            are retrived from the table may differ on master and slave.
            
            Solution: We mark writing to a table with auto_increment table
            as unsafe. This will cause the execution of such statements to
            throw a warning and forces the statement to be logged in ROW if
            the logging format is mixed. 
            
            Changes: 
            1. All the statements that writes to a table with auto_increment 
            column(s) based on the rows fetched from another table, will now
            be unsafe.
            2. CREATE TABLE with SELECT will now be unsafe.
      6df5a61d
  8. 06 Feb, 2012 2 commits
    • Vasil Dimov's avatar
      Merge mysql-5.1 -> mysql-5.5 · c8d8a923
      Vasil Dimov authored
      The actual Bug#11754376 does not exist in MySQL 5.5 because at startup
      we drop entries for temporary tables from InnoDB dictionary cache (only
      if ROW_FORMAT is not REDUNDANT). But nevertheless the bug in
      normalize_table_name_low() is present so we fix it.
      c8d8a923
    • Vasil Dimov's avatar
      Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON · 17afdb90
      Vasil Dimov authored
      GRACEFUL SHUTDOWN
      
      During startup mysql picks up .frm files from the tmpdir directory and
      tries to drop those tables in the storage engine.
      
      The problem is that when tmpdir ends in / then ha_innobase::delete_table()
      is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
      to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
      to delete the table entry from the InnoDB dictionary cache.
      ha_innobase::delete_table() returns an error but nevertheless mysql wipes
      away the .frm file and the entry in the InnoDB dictionary cache remains
      orphaned with no easy way to remove it.
      
      The "no easy" way to remove it is to create a similar temporary table again,
      copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
      tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
      after restart and will try to issue drop table for "/var/tmp/#sql123"
      (notice do double slash), ha_innobase::delete_table() will normalize it to
      "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
      table entry from the dictionary cache.
      
      The solution is to fix normalize_table_name_low() to normalize things like
      "/var/tmp//table" correctly to "tmp/table".
      
      This patch also adds a test function which invokes
      normalize_table_name_low() with various inputs to make sure it works
      correctly and a mtr test that calls this test function.
      
      Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)
      17afdb90
  9. 05 Feb, 2012 1 commit
  10. 03 Feb, 2012 4 commits
  11. 02 Feb, 2012 11 commits