LevelDB storage engine (MDEV-3841)

[MDEV-4032] Session value of leveldb_lock_wait_timeout is ignored Created: 2013-01-14  Updated: 2013-01-14  Resolved: 2013-01-14

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Technical task Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: leveldb

Issue Links:
Relates

 Description   

LevelDB uses the global value of leveldb_lock_wait_timeout, but ignores the session one.

--enable_connect_log
 
create table t1 (pk int primary key, i int) engine=LevelDB;
set global leveldb_lock_wait_timeout = 2;
begin;
insert into t1 values (1,1);
 
--connect (con1,localhost,root,,)
set session leveldb_lock_wait_timeout = 5;
select now();
--error ER_LOCK_WAIT_TIMEOUT
insert into t1 values (1,100);
select now();
 
--connection default
commit;

Output shows that the timeout is 2 seconds, not 5:

create table t1 (pk int primary key, i int) engine=LevelDB;
set global leveldb_lock_wait_timeout = 2;
begin;
insert into t1 values (1,1);
connect  con1,localhost,root,,;
set session leveldb_lock_wait_timeout = 5;
select now();
now()
2013-01-14 17:34:38
insert into t1 values (1,100);
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
select now();
now()
2013-01-14 17:34:40
connection default;
commit;
 

Here is a tiny modification to leveldb.test which also shows the problem (unfortunately, I don't see a better way than sleep):

=== modified file 'mysql-test/t/leveldb.test'
--- mysql-test/t/leveldb.test   2013-01-14 13:15:29 +0000
+++ mysql-test/t/leveldb.test   2013-01-14 14:19:05 +0000
@@ -350,6 +350,7 @@ set leveldb_lock_wait_timeout=1000; # se
   update t17 set col1='UPD2-CC' where pk='row2';
 
 connection con1;
+--sleep 2
 rollback;
 
 connection default;

This part of the test sets the session timeout to 1000 seconds, starts an update, then switches to the connection which holds the lock and releases it. Then it returns to the first connection and checks that the update worked. However, there is no delay anywhere in the process, the operations are fast and well within 1 second, so the test doesn't really check that the timeout value affects the outcome. With the delay, the test starts failing with ER_LOCK_WAIT_TIMEOUT at line 357, which is not supposed to happen.

revision-id: psergey@askmonty.org-20130114131529-qv3531bw9fdklwob
revno: 4483
branch-nick: mysql-5.6-leveldb


Generated at Thu Feb 08 06:53:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.