Details
-
Technical task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
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
|
Attachments
Activity
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
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.