MySQL Bugs: #60155: Platform-dependent test result in innodb.innodb

Bug #60155	Platform-dependent test result in innodb.innodb
Submitted:	17 Feb 2011 4:17	Modified:	17 Feb 2011 18:44
Reporter:	[ name withheld ]	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S3 (Non-critical)
Version:	5.5.9	OS:	Linux (PPC64)
Assigned to:		CPU Architecture:	Any
Tags:	regression

Description:
As of 5.5.9, the  innodb.innodb regression test fails on PPC64, like this:

--- /builddir/build/BUILD/mysql-5.5.9/mysql-test/suite/innodb/r/innodb.result	2011-01-20 01:37:10.000000000 +0300
+++ /builddir/build/BUILD/mysql-5.5.9/mysql-test/suite/innodb/r/innodb.reject	2011-02-16 17:33:04.643408936 +0300
@@ -1664,7 +1664,7 @@
 drop table t1;
 SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_buffer_pool_pages_total';
 variable_value
-511
+513
 SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_page_size';
 variable_value
 16384
mysqltest: Result content mismatch

I see that that test has been modified since 5.5.8 (where it passed).  Probably the number of rows modified went past a threshold that changed the number of pages affected.  The same code passes on x86 and x86_64 platforms, so maybe it's dependent on alignment or endianness considerations.

How to repeat:
Run regression tests on PPC64

Actually, I now notice that the same symptom was seen on ppc32 (but not ppc64) in 5.5.8:

http://ppc.koji.fedoraproject.org/koji/getfile?taskID=127754&name=build.log

So overall it looks like that number isn't really stable enough to have a particular value hard-wired into your expected result.

It might be worth noting that PPC is no longer a supported platform for MySQL 5.5. Things might break due to lack of testing.

Seems like an easy enough fix.

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/4325

https://github.com/mysql/mysql-server/pull/57