MySQL Bugs: #8003: "index_merge_innodb" fails on Linux/PPC

Bug #8003	"index_merge_innodb" fails on Linux/PPC
Submitted:	19 Jan 2005 9:51	Modified:	31 Jan 2005 19:29
Reporter:	Lenz Grimmer	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.3-pre	OS:	Linux (Linux/PPC)
Assigned to:	Sergey Petrunya	CPU Architecture:	Any

Description:
The current 5.0 tree failes the "index_merge_innodb" test with the following diff. This binary was compiled with BUILD/compile-ppc using gcc-3.3.5 (Debian 3.1)

index_merge_innodb             [ fail ]

Errors are (from /home/lenz/my/mysql-5.0-build/mysql-test/var/log/mysqltest-time) :
/home/lenz/my/mysql-5.0-build/client/mysqltest: At line 123: Result length mismatch
(the last lines may be the most important ones)
Below are the diffs between actual and expected results:
-------------------------------------------------------
*** r/index_merge_innodb.result Wed Jan 19 11:19:43 2005
--- r/index_merge_innodb.reject Wed Jan 19 12:41:04 2005
***************
*** 111,117 ****
  select count(*) from t1 where
  key1a = 2 and key1b is null and key2a = 2 and key2b is null;
  count(*)
! 4
  explain select count(*) from t1 where
  key1a = 2 and key1b is null and key3a = 2 and key3b is null;
  id    select_type     table   type    possible_keys   key     key_len ref     rows    Extra
--- 111,117 ----
  select count(*) from t1 where
  key1a = 2 and key1b is null and key2a = 2 and key2b is null;
  count(*)
! 144
  explain select count(*) from t1 where
  key1a = 2 and key1b is null and key3a = 2 and key3b is null;
  id    select_type     table   type    possible_keys   key     key_len ref     rows    Extra
***************
*** 119,123 ****
  select count(*) from t1 where
  key1a = 2 and key1b is null and key3a = 2 and key3b is null;
  count(*)
! 4
  drop table t1,t2;
--- 119,123 ----
  select count(*) from t1 where
  key1a = 2 and key1b is null and key3a = 2 and key3b is null;
  count(*)
! 144
  drop table t1,t2;
-------------------------------------------------------

How to repeat:
Compile with "compile-ppc" on Linux/PPC (pegasos) and observe the test diff above.

Last Changeset for this build attempt:

ChangeSet@1.1813, 2005-01-19 09:14:26+01:00, tulin@build.mysql.com
  Merge bk-internal.mysql.com:/home/bk/mysql-4.1
  into build.mysql.com:/users/tulin/mysql-5.0

Assigned to Sergey for investigation.

Sergey P.,

does the ROR code still rely on table handlers not modifying non-requested fields in the record buffer in the table handle?

As I said in my earlier emails, we can make InnoDB not to touch them, but it is dangerous to rely on that.

And InnoDB needs to know what bits in the null bytes in the record buffer are actually used as SQL NULL value markers of columns, because Sergei G.'s CHECKSUM TABLE assumes that the rest of the bits in those bytes are set to 1.

The safe, robust solution:

both Sergey P. and Sergei G. should write their code so that it does not assume table handlers preserving the data in non-requested columns or bits in the record buffer.

The unsafe, fragile solution:

modify InnoDB code so that it preserves the values in non-requested fields, and resets the unused bits in null bytes to 1. For that, Sergei G. has to tell us how to determine what bits are unused in null bytes.

Regards,

Heikki

This is a showstopper -- it gets in the way of doing test builds, because it even fails on our primary build machine.

ChangeSet@1.1792, 2005-01-22 03:08:17+03:00, sergefp@mysql.com
is reverted,  the final is:
ChangeSet@1.1808, 2005-01-25 07:37:06+03:00, sergefp@mysql.com

No doc change needed.