Details
-
Type:
Technical task
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
Description
One connection starts a slow update, another connection kills the query in the first connection, the query ends with an error, but the changes are still applied.
Test output:
create table t1 (pk int primary key, a int) engine=LevelDB; insert into t1 values (1,10),(2,20); set autocommit = 1; update t1 set a = sleep(10) where pk = 1; connect con1,localhost,root,,; kill query 2; connection default; ERROR 70100: Query execution was interrupted select * from t1; pk a 1 1 2 20
Test case:
--enable_connect_log create table t1 (pk int primary key, a int) engine=LevelDB; insert into t1 values (1,10),(2,20); --let $con_id = `select connection_id()` set autocommit = 1; --send update t1 set a = sleep(10) where pk = 1; --connect (con1,localhost,root,,) eval kill query $con_id; --connection default --error ER_QUERY_INTERRUPTED --reap select * from t1;
revision-id: psergey@askmonty.org-20130115181447-1jfr200qcuqzp1sr revno: 4495 branch-nick: mysql-5.6-leveldb
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The difference will not matter as much when we're able to roll back a statement which is inside a transaction.
(Currently, we accumulate all changes in a single leveldb::WriteBatch, and cannot tell between changes of the last statement and transaction's changes)
Reproducible on
revision-id: psergey@askmonty.org-20130201180328-ocmbh9uvcoedmihp
revno: 4591
branch-nick: mysql-5.6-leveldb
Added a testcase
SQL layer will call
leveldb_rollback (hton=0x196c330, thd=0x7508e30, rollback_trx=false)
which will do nothing, because we assume this is a statement failed (true) inside a transaction (false). I don't see any way a storage engine could tell between a single-statement transaction and a statement inside a bigger transaction.