Test tokudb.locks-select-update-3 is unstable

Bug #1662909 reported by Laurynas Biveinis on 2017-02-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.5
Invalid
Undecided
Unassigned
5.6
Opinion
Low
Unassigned
5.7
Opinion
Low
Unassigned

Bug Description

On 5.6 trunk, ASan build:

tokudb.locks-select-update-3 w3 [ fail ]
        Test ended at 2017-02-06 14:16:01

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;
safe_process[8432]: Child process: 8434, exit: 1

Server [mysqld.1 - pid: 8152, winpid: 8152] log:
Server log from this test:
----------SERVER LOG START-----------
----------SERVER LOG END-------------

tags: added: ci tokudb
Elena Stepanova (elenst) wrote :

We are getting the same failure, although rarely. If a machine or a build is very slow, the part where the test switched to the default connection, runs SELECT and COMMIT, and switches back, can take time, and since the default TokuDB lock timeout is only 4 seconds, the timeout occurs. Since the logic of the test is unrelated to the timeout, it makes sense just to set it to a higher value:

diff --git a/storage/tokudb/mysql-test/tokudb/r/locks-select-update-3.result b/storage/tokudb/mysql-test/tokudb/r/locks-select-update-3.result
index 8b31bf5..c1f05cd 100644
--- a/storage/tokudb/mysql-test/tokudb/r/locks-select-update-3.result
+++ b/storage/tokudb/mysql-test/tokudb/r/locks-select-update-3.result
@@ -8,6 +8,7 @@ select * from t where a=1 for update;
 a b
 1 0
 update t set b=b+1 where a=1;
+set session tokudb_lock_timeout= 60000;
 set session transaction isolation level read committed;
 begin;
 select * from t where a=1 for update;
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.test
index a563f06..5b54fa7 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
@@ -15,6 +15,7 @@ select * from t where a=1 for update;
 # t2 update
 update t set b=b+1 where a=1;
 connect(conn1,localhost,root);
+set session tokudb_lock_timeout= 60000;
 set session transaction isolation level read committed;
 begin;
 # t2 select for update, should hang until t1 commits

Sveta Smirnova (svetasmirnova) wrote :

At the other side this can be easily reproduced on demand if run test as

./mtr --suite=tokudb locks-select-update-3 --mysqld=--tokudb_lock_timeout=50

Repeatable with 5.7 as well

George Ormond Lorch III (gl-az) wrote :

Tracking in https://jira.percona.com/browse/TDB-44, please login there to Percona JIRA and 'watch' for future updates. Marking it as opinion here as there is no other accurate matching state.

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2235

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers