An error occurred fetching the project authors.
  1. 12 May, 2008 1 commit
    • unknown's avatar
      Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables · e7e49eb6
      unknown authored
      The REPAIR TABLE ... USE_FRM query silently corrupts data of tables
      with old .FRM file version.
      The mysql_upgrade client program or the REPAIR TABLE query (without
      the USE_FRM clause) can't prevent this trouble, because in the
      common case they don't upgrade .FRM file to compatible structure.
      
      1. Evaluation of the REPAIR TABLE ... USE_FRM query has been
         modified to reject such tables with the message:
         "Failed repairing incompatible .FRM file".
      
      2. REPAIR TABLE query (without USE_FRM clause) evaluation has been
         modified to upgrade .FRM files to current version.
      
      3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified
         to return error status when .FRM file has incompatible version.
      
      4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE
         FOR UPGRADE and REPAIR TABLE queries, so their behaviors have
         been changed too to upgrade .FRM files with incompatible
         version numbers.
      
      
      mysql-test/std_data/bug36055.MYD:
        Added test data for bug #36055.
      mysql-test/std_data/bug36055.MYI:
        Added test data for bug #36055.
      mysql-test/std_data/bug36055.frm:
        Added test data for bug #36055.
      mysql-test/r/repair.result:
        Added test case for bug# 36055.
      mysql-test/t/repair.test:
        Added test case for bug# 36055.
      sql/handler.cc:
        Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables
        
        The handler::ha_check_for_upgrade method has been modified to
        return error if .FRM file has incompatible version number.
      sql/sql_table.cc:
        Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables
        
        The prepare_for_repair function has been modified to reject
        REPAIR TABLE ... USE_FRM queries on incompatible .FRM files
        with the message: "Failed repairing incompatible .FRM file".
      e7e49eb6
  2. 09 Nov, 2006 1 commit
    • unknown's avatar
      Bug#19371 VARBINARY() have trailing zeros after upgrade from 4.1 · f90f1e30
      unknown authored
       - Detect if a table has field of type MYSQL_TYPE_VAR_STRING while running
         "CHECK TABLE t FOR UPGRADE" and indicate it need to be fixed
         with "REPAIR TABLE t".
       - When running a "REPAIR TABLE t" or "ALTER TABLE t FORCE" on the above
         table, install a special copy function to trim off the trailing spaces
         which we safely can say that the pre 5.0 mysqld didn't put there. 
      
      
      mysql-test/r/varbinary.result:
        Add test to see that a table with varbinary from 4.1 can be REPAIRED
      mysql-test/t/varbinary.test:
        Add test to see that a table with varbinary from 4.1 can be REPAIRED
      sql/field_conv.cc:
        Add new field copy function 'do_field_varbinary_pre50' used for copying
        between MYSQL_TYPE_VAR_STRING and MYSQL_TYPE_VARCHAR. It will remove trailing
        spaces from the field as MySQL <= 4.1 never stores the trailing spaces for
        a MYSQL_TYPE_VAR_STRING.
        Install this new copy function in ALTER TABLEs list of functions to use for
        copying data during and alter if from field is a <= 4.1 varbinary and to
        field is 5.0 varbinary.
      sql/handler.cc:
        If the table has a pre 5.0 varbinary, table not to be altered so the field
        type is upgraded to 5.0 version and trailing space can be trimmed.
      mysql-test/std_data/bug19371.MYD:
        New BitKeeper file ``mysql-test/std_data/bug19371.MYD''
      mysql-test/std_data/bug19371.MYI:
        New BitKeeper file ``mysql-test/std_data/bug19371.MYI''
      mysql-test/std_data/bug19371.frm:
        New BitKeeper file ``mysql-test/std_data/bug19371.frm''
      f90f1e30