MySQL Bugs: #41332: Insert into partitioned "ndbcluster" table causes server crash

Bug #41332	Insert into partitioned "ndbcluster" table causes server crash
Submitted:	9 Dec 2008 17:01	Modified:	12 Jan 12:16
Reporter:	Joerg Bruehe
Status:	Duplicate
Category:	Server: Cluster	Severity:	S1 (Critical)
Version:	Cluster 6.3.20	OS:	Any
Assigned to:	Mattias Jonsson	Target Version:
Triage:	Needs Triage: D2 (Serious)

Description:
These three tests are new in 5.1.28, and will be taken only if "cluster" is configured,
so they are not run in any normal 5.1 (release) build:
   parts.partition_mgm_lc0_ndb
   parts.partition_mgm_lc1_ndb
   parts.partition_mgm_lc2_ndb

Their first run in a release build is with cluster-6.3.20 (based on 5.1.30), and here
they fail on all platforms in the same way:

=====
parts.partition_mgm_lc0_ndb    [ fail ]

mysqltest: In included file "./suite/parts/inc/partition_mgm.inc": At line 36: query
'INSERT INTO TableA VALUE
S (1), (2), (7), (8), (9), (10)' failed: 2013: Lost connection to MySQL server during
query

The result from queries just before the failure was:
# Creating database MySQL_TEST_DB
CREATE DATABASE MySQL_Test_DB;
USE MySQL_Test_DB;
# 1.0 KEY partitioning mgm
# Creating KEY partitioned table
CREATE TABLE TableA (a INT)
ENGINE = 'NDBCluster'
PARTITION BY KEY (a)
(PARTITION parta ,
PARTITION partB ,
PARTITION Partc ,
PARTITION PartD );
INSERT INTO TableA VALUES (1), (2), (7), (8), (9), (10);

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

Stopping All Servers
=====

=====
parts.partition_mgm_lc1_ndb    [ fail ]

mysqltest: In included file "./suite/parts/inc/partition_mgm.inc": At line 36: query
'INSERT INTO TableA VALUE
S (1), (2), (7), (8), (9), (10)' failed: 2013: Lost connection to MySQL server during
query

The result from queries just before the failure was:
# Creating database MySQL_TEST_DB
CREATE DATABASE MySQL_Test_DB;
USE MySQL_Test_DB;
# 1.0 KEY partitioning mgm
# Creating KEY partitioned table
CREATE TABLE TableA (a INT)
ENGINE = 'NDBCluster'
PARTITION BY KEY (a)
(PARTITION parta ,
PARTITION partB ,
PARTITION Partc ,
PARTITION PartD );
INSERT INTO TableA VALUES (1), (2), (7), (8), (9), (10);

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

Stopping All Servers
=====

=====
parts.partition_mgm_lc2_ndb    [ fail ]

mysqltest: In included file "./suite/parts/inc/partition_mgm.inc": At line 36: query
'INSERT INTO TableA VALUE
S (1), (2), (7), (8), (9), (10)' failed: 2013: Lost connection to MySQL server during
query

The result from queries just before the failure was:
# Creating database MySQL_TEST_DB
CREATE DATABASE MySQL_Test_DB;
USE MySQL_Test_DB;
# 1.0 KEY partitioning mgm
# Creating KEY partitioned table
CREATE TABLE TableA (a INT)
ENGINE = 'NDBCluster'
PARTITION BY KEY (a)
(PARTITION parta ,
PARTITION partB ,
PARTITION Partc ,
PARTITION PartD );
INSERT INTO TableA VALUES (1), (2), (7), (8), (9), (10);

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

Stopping All Servers
=====

How to repeat:
Just run the full tests, including the "parts" suite.

It works in mysql-5.1-bugteam, and is disabled in mysql-6.0-bugteam due to bug#38778.

I'm looking into why it fails in this specific tree...

Duplicate of bug#40709.
It works in mysql-5.1 (and sort of in mysql-6.0, accept for a crash in a ndb node,
bug#38778...)

A fix for this tree until bug#40709 is fixed is to simply add a key to the column 'a':
=== modified file 'mysql-test/suite/parts/inc/partition_mgm.inc'
--- mysql-test/suite/parts/inc/partition_mgm.inc	2008-07-10 23:14:13 +0000
+++ mysql-test/suite/parts/inc/partition_mgm.inc	2009-01-12 10:46:25 +0000
@@ -26,7 +26,7 @@
 USE MySQL_Test_DB;
 --echo # 1.0 KEY partitioning mgm
 --echo # Creating KEY partitioned table
-eval CREATE TABLE TableA (a INT)
+eval CREATE TABLE TableA (a INT PRIMARY KEY)
 ENGINE = $engine
 PARTITION BY KEY (a)
 (PARTITION parta $part_optA,

This does not fix bug#38778.

For the record, and no surprise: Same failure in cluster-6.3.24.

Note: It (still) affects all platforms.

IMO, changing the test and declaring the column "primary key"
will just hide the problem - I am not so much concerned that the test fails
but rather that
a) legal SQL causes a crash on all platforms
   (if this violates a known restriction, then it should be caught
   and rejected with an error message), and
b) that this test, which is part of our sources,
   is not run during development.