1. 09 Feb, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE · 31c990ca
      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.
      
      sql/share/errmsg-utf8.txt:
        Added new warning messages.
      sql/sql_base.cc:
        -Created function to check statements that write to 
         tables with auto_increment column and has select.
        -Marked all the statements that write to a table
         with auto_increment column based on rows fetched
         from other table(s) as unsafe.
      sql/sql_table.cc:
        mark CREATE TABLE[with auto_increment column] as unsafe.
      31c990ca
  2. 08 Feb, 2012 1 commit
  3. 07 Feb, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE · de85a600
      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.
      
      
      sql/share/errmsg-utf8.txt:
        Added new Warning messages
      sql/sql_base.cc:
        created a new function that checks for select + write on a autoinc table
        made all such statements to be unsafe.
      sql/sql_parse.cc:
        made create autoincremnet tabble + select unsafe
      de85a600
  4. 06 Feb, 2012 2 commits
    • Vasil Dimov's avatar
      Merge mysql-5.1 -> mysql-5.5 · 56e3f68c
      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.
      56e3f68c
    • Vasil Dimov's avatar
      Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON · 1c4fd3bb
      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/)
      1c4fd3bb
  5. 05 Feb, 2012 1 commit
  6. 03 Feb, 2012 4 commits
  7. 02 Feb, 2012 11 commits
  8. 01 Feb, 2012 1 commit
  9. 31 Jan, 2012 11 commits
  10. 30 Jan, 2012 5 commits
  11. 27 Jan, 2012 1 commit
  12. 26 Jan, 2012 1 commit