Description:
This test failure hasn't been reported previously because there were so many others, more frequent ones, but now I get to this one, too:
The error message is "Cannot start new thread for query" when test "lock_multi_bug38691" is run "embedded".
It is specific to HP-UX 11.23, and it has occurred in (at least) 5.1.40, 5.4.2, 5.5.0, and 5.5.1.
(For 5.1.41 and 5.1.42, test failures have not been analyzed.)
There are two minor variations where exactly it happens:
=====
main.lock_multi_bug38691 [ retry-fail ]
Test ended at YYYY-MM-DD HH:MM:SS
CURRENT_TEST: main.lock_multi_bug38691
mysqltest: At line NNN: Cannot start new thread for query
The result from queries just before the failure was:
SET @odl_sync_frm = @@global.sync_frm;
SET @@global.sync_frm = OFF;
DROP TABLE IF EXISTS t1,t2,t3;
CREATE TABLE t1 (
a int(11) unsigned default NULL,
b varchar(255) default NULL,
UNIQUE KEY a (a),
KEY b (b)
);
INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3);
CREATE TABLE t2 SELECT * FROM t1;
CREATE TABLE t3 SELECT * FROM t1;
# test altering of columns that multiupdate doesn't use
# normal mode
# PS mode
# test altering of columns that multiupdate uses
# normal mode
- saving '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' to '/PATH/mysql-test/var/log/main.lock_multi_bug38691/'
=====
=====
main.lock_multi_bug38691 [ retry-fail ]
Test ended at YYYY-MM-DD HH:MM:SS
CURRENT_TEST: main.lock_multi_bug38691
mysqltest: At line NNN: Cannot start new thread for query
The result from queries just before the failure was:
SET @odl_sync_frm = @@global.sync_frm;
SET @@global.sync_frm = OFF;
DROP TABLE IF EXISTS t1,t2,t3;
CREATE TABLE t1 (
a int(11) unsigned default NULL,
b varchar(255) default NULL,
UNIQUE KEY a (a),
KEY b (b)
);
INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3);
CREATE TABLE t2 SELECT * FROM t1;
CREATE TABLE t3 SELECT * FROM t1;
# test altering of columns that multiupdate doesn't use
# normal mode
- saving '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' to '/PATH/mysql-test/var/log/main.lock_multi_bug38691/'
=====
How to repeat:
Found while running the test suite.
Suggested fix:
HP-UX 11.23 is not our fastest platform -
is there a possibility of a race condition between some task ending and a new one starting, so that some delay would help?
Description: This test failure hasn't been reported previously because there were so many others, more frequent ones, but now I get to this one, too: The error message is "Cannot start new thread for query" when test "lock_multi_bug38691" is run "embedded". It is specific to HP-UX 11.23, and it has occurred in (at least) 5.1.40, 5.4.2, 5.5.0, and 5.5.1. (For 5.1.41 and 5.1.42, test failures have not been analyzed.) There are two minor variations where exactly it happens: ===== main.lock_multi_bug38691 [ retry-fail ] Test ended at YYYY-MM-DD HH:MM:SS CURRENT_TEST: main.lock_multi_bug38691 mysqltest: At line NNN: Cannot start new thread for query The result from queries just before the failure was: SET @odl_sync_frm = @@global.sync_frm; SET @@global.sync_frm = OFF; DROP TABLE IF EXISTS t1,t2,t3; CREATE TABLE t1 ( a int(11) unsigned default NULL, b varchar(255) default NULL, UNIQUE KEY a (a), KEY b (b) ); INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3); CREATE TABLE t2 SELECT * FROM t1; CREATE TABLE t3 SELECT * FROM t1; # test altering of columns that multiupdate doesn't use # normal mode # PS mode # test altering of columns that multiupdate uses # normal mode - saving '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' to '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' ===== ===== main.lock_multi_bug38691 [ retry-fail ] Test ended at YYYY-MM-DD HH:MM:SS CURRENT_TEST: main.lock_multi_bug38691 mysqltest: At line NNN: Cannot start new thread for query The result from queries just before the failure was: SET @odl_sync_frm = @@global.sync_frm; SET @@global.sync_frm = OFF; DROP TABLE IF EXISTS t1,t2,t3; CREATE TABLE t1 ( a int(11) unsigned default NULL, b varchar(255) default NULL, UNIQUE KEY a (a), KEY b (b) ); INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3); CREATE TABLE t2 SELECT * FROM t1; CREATE TABLE t3 SELECT * FROM t1; # test altering of columns that multiupdate doesn't use # normal mode - saving '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' to '/PATH/mysql-test/var/log/main.lock_multi_bug38691/' ===== How to repeat: Found while running the test suite. Suggested fix: HP-UX 11.23 is not our fastest platform - is there a possibility of a race condition between some task ending and a new one starting, so that some delay would help?