From: Date: May 5 2008 9:40pm
Subject: bk commit into 5.0 tree (gshchepa:1.2614) BUG#36055
List-Archive: http://lists.mysql.com/commits/46368
X-Bug: 36055
Message-Id: <20080505194148.4368640C90C@localhost.localdomain>

Below is the list of changes that have just been committed into a local
5.0 repository of gshchepa.  When gshchepa does a push these changes
will be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@stripped, 2008-05-06 00:40:38+05:00, gshchepa@stripped +2 -0
  Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables
  
  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.

  sql/handler.cc@stripped, 2008-05-06 00:40:27+05:00, gshchepa@stripped +2 -0
    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@stripped, 2008-05-06 00:40:31+05:00, gshchepa@stripped +7 -0
    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".

diff -Nrup a/sql/handler.cc b/sql/handler.cc
--- a/sql/handler.cc	2008-02-07 06:09:59 +04:00
+++ b/sql/handler.cc	2008-05-06 00:40:27 +05:00
@@ -1980,6 +1980,8 @@ int handler::ha_check_for_upgrade(HA_CHE
       }
     }
   }
+  if (table->s->frm_version != FRM_VER_TRUE_VARCHAR)
+    return HA_ADMIN_NEEDS_ALTER;
   return check_for_upgrade(check_opt);
 }
 
diff -Nrup a/sql/sql_table.cc b/sql/sql_table.cc
--- a/sql/sql_table.cc	2008-01-23 19:01:29 +04:00
+++ b/sql/sql_table.cc	2008-05-06 00:40:31 +05:00
@@ -2118,6 +2118,13 @@ static int prepare_for_repair(THD* thd, 
   const char **ext= table->file->bas_ext();
   MY_STAT stat_info;
 
+  if (table->s->frm_version != FRM_VER_TRUE_VARCHAR)
+  {
+    error= send_check_errmsg(thd, table_list, "repair",
+                             "Failed reparing incompatible .FRM file");
+    goto end;
+  }
+
   /*
     Check if this is a table type that stores index and data separately,
     like ISAM or MyISAM. We assume fixed order of engine file name