Bug #37153 NDB Cluster reports affected rows incorrectly

• Submitted: 3 Jun 2008 9:03
• Modified: 26 Sep 2008 15:42
• Reporter: Max Mether
• Status: Closed
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S2 (Serious)
• Version: CGE >= 6.3.11
• OS: Any
• Assigned to: Frazer Clement
• CPU Architecture: Any

[3 Jun 2008 9:03] Max Mether

Description:
When doing a DELETE operation using a primary key value that does not exist the Cluster incorretly reports 1 affected row. 

How to repeat:
mysql> CREATE TABLE t1 (a int not null primary key, b char(3)) engine = ndb;
Query OK, 0 rows affected (1.24 sec)

mysql> DELETE FROM t1 WHERE a = 200;
Query OK, 1 row affected (0.03 sec)

[3 Jun 2008 10:30] Hartmut Holzgraefe

Can't reproduce with ndb-6.3.10, building ndb-6.3.14 now

[3 Jun 2008 19:13] Hartmut Holzgraefe

ndb-6.3.14 does indeed show 1 affected row, not zero

now building 6.3.11-13 to see where this changed ...

[3 Jun 2008 21:28] Hartmut Holzgraefe

ndb-6.3.10 is the last OK version, the problem exists starting with ndb-6.3.11

[24 Sep 2008 8:52] Geert Vanderkelen

Doesn't have to be a DELETE, UPDATE shows problem too, on an empty table (using current 6.3bzr):

mysql> update t1 set vc='something' where id = 28;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

[24 Sep 2008 15:22] Frazer Clement

Fix pushed to 6.3.18 and 6.4.0

[26 Sep 2008 15:42] Jon Stephens

Documented in the 5.1.28-ndb-6.3.18 changelog as follows:

        A statement of the form 'DELETE FROM table WHERE primary_key=value'
        or 'UPDATE table WHERE primary_key=value' where there was no row whose 
        primary key column had the stated value appeared to succeed, with the 
        server reporting that 1 row had been changed.
      
        This issue was only known to affect MySQL Cluster NDB 6.3.11 and later
        NDB 6.3 versions.