MySQL Bugs: #34208: Wrong select results returned by cluster

Bug #34208	Wrong select results returned by cluster
Submitted:	31 Jan 2008 21:55	Modified:	2 Apr 2008 19:35
Reporter:	Joerg Bruehe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	5.1.23-rc	OS:	Linux (IA64, icc)
Assigned to:	Kristian Nielsen	CPU Architecture:	Any
Tags:	sr51RC

Description:
This bug happened in the 5.1.23-rc build
on exactly those platforms which also suffer from bug#31239.

As this here is also in the "select" area, I suspect it may just be another way of the 31239 problem showing up:

::::::::::::::
ndb.ndb_update                 [ fail ]

mysqltest: At line NNN: query 'update ignore t1 set b = 55 where pk1 = 14' failed: 1032: Can't find record in 't1'

The result from queries just before the failure was:
< snip >
0       0       0
2       2       2
4       1       1
UPDATE t1 set pk1 = 1, c = 2 where pk1 = 4;
ERROR 23000: Duplicate entry '2' for key 'c'
UPDATE IGNORE t1 set pk1 = 1, c = 2 where pk1 = 4;
select * from t1 order by pk1;
pk1     b       c
0       0       0
2       2       2
4       1       1
UPDATE t1 set pk1 = pk1 + 10;
select * from t1 order by pk1;
pk1     b       c
10      0       0
12      2       2
14      1       1
create unique index ib on t1(b);
update t1 set c = 4 where pk1 = 12;
update ignore t1 set b = 55 where pk1 = 14;

More results from queries before failure can be found in /PATH/mysql-test/var/log/ndb_update.log

Stopping All Servers
::::::::::::::

::::::::::::::
ndb.ndb_index_unique           [ fail ]

mysqltest: At line NNN: query 'create unique index ib on t1(b)' succeeded - should have failed with errno 1169...

The result from queries just before the failure was:
< snip >
2       3       5
3       4       6
4       5       8
5       6       2
6       7       2
7       8       3
delete from t1 where a = 1;
insert into t1 values(8, 2, 3);
select * from t1 order by a;
a       b       c
2       3       5
3       4       6
4       5       8
5       6       2
6       7       2
7       8       3
8       2       3
alter table t1 drop index ib;
insert into t1 values(1, 2, 3);
create unique index ib on t1(b);

More results from queries before failure can be found in /PATH/mysql-test/var/log/ndb_index_unique.log

Stopping All Servers
::::::::::::::

How to repeat:
Found by running the test suite.

Manage to verify on ia64 RHAS4.

Build command:

CC="icc -static-intel" CXX="icpc -static-intel" CFLAGS="-O3 -g -unroll2 -ip -mp -restrict -no-ftz -no-prefetch" CXXFLAGS="-O3 -g -unroll2 -ip -mp -restrict -no-ftz -no-prefetch" LDFLAGS="" ./configure --disable-shared --with-ndbcluster --without-innodb --with-csv-storage-engine --with-archive-storage-engine --with-blackhole-storage-engine --with-example-storage-engine --with-federated-storage-engine --without-embedded-server --without-bench --with-zlib-dir=bundled --with-big-tables --enable-assembler --enable-local-infile --with-mysqld-user=mysql --with-unix-socket-path=/var/lib/mysql/mysql.sock --with-pic --prefix=/ --with-extra-charsets=all --exec-prefix=/usr --libexecdir=/usr/sbin --libdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var/lib/mysql --infodir=/usr/share/info --includedir=/usr/include --mandir=/usr/share/man --enable-thread-safe-client

make

Minimal test script:

-----------------------------------------------------------------------
-- source include/have_ndb.inc
-- source include/not_embedded.inc

--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings

CREATE TABLE t1 (
  pk1 INT NOT NULL PRIMARY KEY,
  b INT NOT NULL,
  c INT NOT NULL UNIQUE
) ENGINE=ndbcluster;

INSERT INTO t1 VALUES (10, 0, 0),(14,1,1),(12,2,4);
create unique index ib on t1(b);
update ignore t1 set b = 55 where pk1 = 14;
select * from t1 order by pk1;

DROP TABLE t1;
-----------------------------------------------------------------------

The problem occurs during index triggers.

For the update of b from 1 to 55, an internal trigger fires to delete the old
unique index entry for b=1. But this fails to locate the entry for b=1, hence
returns error 626.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/43740

ChangeSet@1.2533, 2008-03-11 09:38:25+01:00, knielsen@ymer.(none) +1 -0
  BUG#34208: Corrupt unique hash index creation due to Intel compiler bug
  on ia64.
  
  Looks like the Intel compiler on ia64 miscompiles post-increments in
  complex array expressions. This caused unique hash index creation to
  build a completely wrong index due to using values from the wrong
  column.
  
  Worked-around by moving the increment to a separate statement.

The patch is quite similar to the one for BUG#31239, though in a completely different part of the code.

The expression &list.id[list.sz++] is compiled to the address of the element _after_ increment, not before, so we set list.id[1] instead of list.id[0]. Rewriting to not use autoincrement removes the problem.

I strongly suspect a compiler bug here, I do not see anything wrong in the source.
However, I was unable to reproduce the problem with a stand-alone example.

Pushed into mysql-5.1-new-ndb

(from there it will eventually be merged into mysql-5.1, mysql-5.1-telco-6.2, mysql-5.1-telco-6.3, mysql-5.1-telco-6.4, mysql-6.0, and mysql-6.0-telco).

Documented in the 5.1.23-ndb-6.3.11 changelog as follows:

        An UPDATE that set a new value for a unique key column could cause
        subsequent queries to fail. 

Left bug in Patch Queued state pending further merges.

Also documented in ndb-6.2.16 changelog.

Pushed into 6.0.6-alpha  (revid:sp1r-knielsen@ymer.(none)-20080311083825-20390) (version source revid:sp1r-tomas@poseidon.ndb.mysql.com-20080516085603-30848) (pib:5)