Details
Description
http://buildbot.askmonty.org/buildbot/builders/bld-dan-release/builds/4308/steps/test_1/logs/stdio
tokudb.locks-select-update-3 w2 [ fail ]
|
Test ended at 2016-10-26 04:25:57
|
|
|
CURRENT_TEST: tokudb.locks-select-update-3
|
mysqltest: At line 27: query 'reap' failed: 1205: Lock wait timeout exceeded; try restarting transaction
|
|
|
The result from queries just before the failure was:
|
SET DEFAULT_STORAGE_ENGINE='tokudb';
|
drop table if exists t;
|
create table t (a int primary key, b int);
|
insert into t values (1,0);
|
set session transaction isolation level read committed;
|
begin;
|
select * from t where a=1 for update;
|
a b
|
1 0
|
update t set b=b+1 where a=1;
|
set session transaction isolation level read committed;
|
begin;
|
select * from t where a=1 for update;
|
commit;
|
Attachments
Issue Links
- relates to
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- links to
Activity
The upstream bug: https://bugs.launchpad.net/percona-server/+bug/1662909.
I've added a suggestion to change the timeout, but will also do it in our tree for now.
The failure is rare (only 4 recorded occasions), but the reason seems obvious, the problem is easily reproducible with the additional sleep:
diff --git a/storage/tokudb/mysql-test/tokudb/t/locks-select-update-3.test b/storage/tokudb/mysql-test/tokudb/t/locks-select-update-3.testindex a563f06..3d0c018 100644--- a/storage/tokudb/mysql-test/tokudb/t/locks-select-update-3.test+++ b/storage/tokudb/mysql-test/tokudb/t/locks-select-update-3.test@@ -21,6 +21,7 @@ begin;send select * from t where a=1 for update;connection default;# t1 commit+--sleep 4commit;connection conn1;# t2 select for update returnsDefault tokudb_lock_timeout is only 4 seconds, it's not much; if on whatever reason SELECT or COMMIT take time, the timeout can be exceeded.