Bug #46160 ha_innobase::check_if_incompatible_data may be wrong when used for 5.1.36
Submitted: 14 Jul 2009 5:59 Modified: 30 Sep 2009 19:59
Reporter: Yasufumi Kinoshita Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB Plugin storage engine Severity:S3 (Non-critical)
Version:5.1.36 + 1.0.3 OS:Any
Assigned to: Vasil Dimov CPU Architecture:Any
Tags: Contribution
Triage: Needs Triage: D2 (Serious)

[14 Jul 2009 5:59] Yasufumi Kinoshita
Description:
When 1.0.3 with 5.1.36, without the following patch, some mysql-test scripts result in fail.
Plugin may need to be fixed along with http://lists.mysql.com/commits/75258

How to repeat:
executing some mysql-test scripts

main.innodb
main.innodb_mysql
main.innodb-index
etc...

(all scripts should be patched by .patch files in the Plugin source)

Suggested fix:
diff -ru innodb_plugin-1.0.3_orig/handler/ha_innodb.cc innodb_plugin-1.0.3_tmp/handler/ha_innodb.cc
--- innodb_plugin-1.0.3_orig/handler/ha_innodb.cc       2009-07-14 13:51:44.000000000 +0900
+++ innodb_plugin-1.0.3_tmp/handler/ha_innodb.cc        2009-07-14 14:46:54.000000000 +0900
@@ -9319,7 +9319,8 @@

        /* Check that row format didn't change */
        if ((info->used_fields & HA_CREATE_USED_ROW_FORMAT) &&
-           get_row_type() != info->row_type) {
+           get_row_type() != ((info->row_type == ROW_TYPE_DEFAULT)
+                               ? ROW_TYPE_COMPACT : info->row_type)) {

                return(COMPATIBLE_DATA_NO);
        }
[14 Jul 2009 9:24] Sveta Smirnova
Thank you for the report.

Verified as described.
[14 Jul 2009 9:32] Sveta Smirnova
Failed tests in my case are:  main.innodb main.innodb_mysql main.innodb_bug42101-nonzero main.innodb-semi-consistent main.innodb_bug21704 main.innodb_bug42101
[15 Jul 2009 12:24] Vasil Dimov
Yasufumi,

The tests do not fail for me with the latest version of the plugin that is not published yet, Marko committed this change recently:

------------------------------------------------------------------------
r5392 | marko | 2009-06-22 14:58:20 +0300 (Mon, 22 Jun 2009) | 4 lines
Changed paths:
   M /branches/zip/handler/ha_innodb.cc

branches/zip: ha_innobase::check_if_incompatible_data(): When
ROW_FORMAT=DEFAULT, do not compare to get_row_type().
Without this change, fast index creation will be disabled
in recent versions of MySQL 5.1.
------------------------------------------------------------------------

--- cut ---
Index: handler/ha_innodb.cc
===================================================================
--- handler/ha_innodb.cc	(revision 5391)
+++ handler/ha_innodb.cc	(revision 5392)
@@ -9183,14 +9183,15 @@ ha_innobase::check_if_incompatible_data(
 		info->auto_increment_value != 0) {
 
 		return(COMPATIBLE_DATA_NO);
 	}
 
 	/* Check that row format didn't change */
-	if ((info->used_fields & HA_CREATE_USED_ROW_FORMAT) &&
-	    get_row_type() != info->row_type) {
+	if ((info->used_fields & HA_CREATE_USED_ROW_FORMAT)
+	    && info->row_type != ROW_TYPE_DEFAULT
+	    && info->row_type != get_row_type()) {
 
 		return(COMPATIBLE_DATA_NO);
 	}
 
 	/* Specifying KEY_BLOCK_SIZE requests a rebuild of the table. */
 	if (info->used_fields & HA_CREATE_USED_KEY_BLOCK_SIZE) {
--- cut ---
[15 Jul 2009 13:14] Vasil Dimov
Yasufumi,

I think your patch is unnecessary restrictive, please verify my analysis:

If the newly specified row format (info->row_type) is ROW_TYPE_DEFAULT, then your patch will check whether the current format (get_row_type()) is ROW_TYPE_COMPACT and will return COMPATIBLE_DATA_NO if it is not. I think this is unnecessary and COMPATIBLE_DATA_YES should be returned in this case because if info->row_type==ROW_TYPE_DEFAULT this means that no ROW_FORMAT= has been specified in the SQL and so the format remains whatever it has been and the new and the old table definitions are compatible.

What do you think?
[29 Sep 2009 10:21] Vasil Dimov
This has been fixed in r5392 and has been released in InnoDB Plugin 1.0.4.
[30 Sep 2009 19:59] Paul Dubois
Noted in 5.4.2 changelog.

For InnoDB tables, an unnecessary table rebuild for ALTER TABLE could
sometimes occur if ROW_FORMAT was specified.