revision-id: 70e12615732d658939972b24da162de8d57086f0 (fb-prod201801-226-g70e12615732) parent(s): cd66b2e5f14a40f581b639f64ed74ad3b0f9f37d author: Sergei Petrunia committer: Sergei Petrunia timestamp: 2019-04-29 13:17:06 +0300 message: Make rocksdb.range_locking test to be run in forward and backward-ordered CFs (one test that makes assumptions about physical record ordering is only enabled in forward ordered cfs) --- mysql-test/suite/rocksdb/r/range_locking.result | 44 ++- .../suite/rocksdb/r/range_locking_rev_cf.result | 341 +++++++++++++++++ mysql-test/suite/rocksdb/t/range_locking.inc | 414 +++++++++++++++++++++ mysql-test/suite/rocksdb/t/range_locking.test | 386 +------------------ .../suite/rocksdb/t/range_locking_rev_cf.test | 12 + rocksdb | 2 +- 6 files changed, 803 insertions(+), 396 deletions(-) diff --git a/mysql-test/suite/rocksdb/r/range_locking.result b/mysql-test/suite/rocksdb/r/range_locking.result index 439e9c6fb00..0518260f53a 100644 --- a/mysql-test/suite/rocksdb/r/range_locking.result +++ b/mysql-test/suite/rocksdb/r/range_locking.result @@ -2,8 +2,9 @@ show variables like 'rocksdb_use_range_locking'; Variable_name Value rocksdb_use_range_locking ON create table t1 ( -pk int primary key, -a int +pk int, +a int, +primary key (pk) comment 'default' ) engine=rocksdb; insert into t1 values (10,10),(20,20),(30,30); @@ -54,9 +55,10 @@ connection con1; rollback; ## Test that locks are not released when a statement in the transaction create table t2 ( -pk int primary key, +pk int, a int, -unique key(a) +primary key (pk) comment 'default', +unique key(a) comment 'default' ) engine=rocksdb; insert into t2 values (1,1),(2,2); begin; @@ -79,8 +81,9 @@ drop table t1; # Test INFORMATION_SCHEMA.lock_info in range-locking mode # create table t1 ( -pk int primary key, -a int +pk int, +a int, +primary key (pk) comment 'default' ) engine=rocksdb; insert into t1 values (10,10),(20,20),(30,30); @@ -117,7 +120,7 @@ create table t1 ( kp1 int not null, kp2 int not null, a int, -primary key(kp1, kp2) +primary key(kp1, kp2) comment 'default' ) engine=rocksdb; insert into t1 select 1, a, 1234 from t0; insert into t1 select 2, a, 1234 from t0; @@ -157,7 +160,7 @@ create table t1 ( kp1 int not null, kp2 int not null, a int, -key(kp1, kp2) +key(kp1, kp2) comment 'default' ) engine=rocksdb; insert into t1 select 1, a, 1234 from t0; insert into t1 values (2, 3, 1234); @@ -229,7 +232,11 @@ drop table t1; # # Same test as above, but check the range scan # -create table t1 (pk int primary key, a int) engine=rocksdb; +create table t1 ( +pk int, +a int, +primary key (pk) comment 'default' +) engine=rocksdb; insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); connect con1,localhost,root,,; # TRX1: Start, Allocate a snapshot @@ -267,7 +274,11 @@ drop table t1; # # Same as above, but test SELECT FOR UPDATE. # -create table t1 (pk int primary key, a int) engine=rocksdb; +create table t1 ( +pk int, +a int, +primary key (pk) comment 'default' +) engine=rocksdb; insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); connect con1,localhost,root,,; # TRX1: Start, Allocate a snapshot @@ -305,7 +316,12 @@ drop table t1; # Another no-snapshot-checking test, this time for single-statement # transaction # -create table t1 (pk int primary key, a int, name varchar(16)) engine=rocksdb; +create table t1 ( +pk int, +a int, +name varchar(16), +primary key(pk) comment 'default' +) engine=rocksdb; insert into t1 values (1,1, 'row1'), (2,2,'row2'); connect con1,localhost,root,,; connection con1; @@ -339,7 +355,11 @@ drop table t1; # # Check that I_S.processlist.state is set correctly now. # -create table t1(pk int primary key, a int) engine=rocksdb; +create table t1( +pk int, +a int, +primary key(pk) comment 'default' +) engine=rocksdb; insert into t1 values (1,1),(2,2),(3,3); begin; select * from t1 where pk=2 for update; diff --git a/mysql-test/suite/rocksdb/r/range_locking_rev_cf.result b/mysql-test/suite/rocksdb/r/range_locking_rev_cf.result new file mode 100644 index 00000000000..444c51162cd --- /dev/null +++ b/mysql-test/suite/rocksdb/r/range_locking_rev_cf.result @@ -0,0 +1,341 @@ +show variables like 'rocksdb_use_range_locking'; +Variable_name Value +rocksdb_use_range_locking ON +create table t1 ( +pk int, +a int, +primary key (pk) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 values +(10,10),(20,20),(30,30); +connect con1,localhost,root,,; +connect con2,localhost,root,,; +### Test: check that range lock inhibits a point lock +connection con1; +begin; +select * from t1 where pk between 5 and 25 for update; +pk a +10 10 +20 20 +connection con2; +insert into t1 values (15,15); +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.PRIMARY +connection con1; +rollback; +## Test: check that range lock inhibits another range lock +## (It should not, but currently it does) +connection con1; +begin; +select * from t1 where pk between 5 and 25 for update; +pk a +10 10 +20 20 +connection con2; +begin; +select * from t1 where pk between 15 and 35 for update; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.PRIMARY +rollback; +connection con1; +rollback; +## Test: check that regular read does not get a range lock +connection con1; +begin; +select * from t1 where pk between 5 and 25; +pk a +10 10 +20 20 +connection con2; +begin; +select * from t1 where pk between 15 and 35 for update; +pk a +20 20 +30 30 +rollback; +connection con1; +rollback; +## Test that locks are not released when a statement in the transaction +create table t2 ( +pk int, +a int, +primary key (pk) comment 'rev:cf1', +unique key(a) comment '' +) engine=rocksdb; +insert into t2 values (1,1),(2,2); +begin; +insert into t2 values (3,3); +insert into t2 values (10,2); +ERROR 23000: Duplicate entry '2' for key 'a' +connection con2; +begin; +select * from t2 where pk=3 for update; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t2.PRIMARY +rollback; +connection con1; +rollback; +drop table t2; +connection default; +disconnect con1; +disconnect con2; +drop table t1; +# +# Test INFORMATION_SCHEMA.lock_info in range-locking mode +# +create table t1 ( +pk int, +a int, +primary key (pk) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 values +(10,10),(20,20),(30,30); +begin; +select * from t1 where pk=10 for update; +pk a +10 10 +select * from information_schema.rocksdb_locks; +COLUMN_FAMILY_ID TRANSACTION_ID KEY MODE +0 15 00000001078000000a X +delete from t1 where pk between 25 and 40; +select * from information_schema.rocksdb_locks; +COLUMN_FAMILY_ID TRANSACTION_ID KEY MODE +0 15 000000010780000019 - 010000010780000028 X +0 15 00000001078000000a X +rollback; +begin; +# The following will show a range lock on 2-9 and also a point lock on 10. +# This is how things currently work. +select * from t1 where pk between 2 and 9 for update; +pk a +select * from information_schema.rocksdb_locks; +COLUMN_FAMILY_ID TRANSACTION_ID KEY MODE +0 16 00000001078000000a X +0 16 000000010780000002 - 010000010780000009 X +rollback; +drop table t1; +# +# MDEV-18104: MyRocks-Gap-Lock: range locking bounds are incorrect for multi-part keys +# +create table t0(a int); +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); +create table t1 ( +kp1 int not null, +kp2 int not null, +a int, +primary key(kp1, kp2) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 select 1, a, 1234 from t0; +insert into t1 select 2, a, 1234 from t0; +insert into t1 select 3, a, 1234 from t0; +connect con1,localhost,root,,; +connection con1; +begin; +select * from t1 where kp1=2 for update; +kp1 kp2 a +2 0 1234 +2 1 1234 +2 2 1234 +2 3 1234 +2 4 1234 +2 5 1234 +2 6 1234 +2 7 1234 +2 8 1234 +2 9 1234 +connection default; +# The lock on kp1=2 should inhibit the following INSERT: +insert into t1 values ( 2,5,9999); +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.PRIMARY +rollback; +connection con1; +rollback; +connection default; +disconnect con1; +drop table t0,t1; +# +# Test that locks on ranges on non-unique secondary keys inhibit +# modifications of the contents of these ranges +# +create table t0(a int); +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); +create table t1 ( +kp1 int not null, +kp2 int not null, +a int, +key(kp1, kp2) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 select 1, a, 1234 from t0; +insert into t1 values (2, 3, 1234); +insert into t1 values (2, 5, 1234); +insert into t1 values (2, 7, 1234); +insert into t1 select 3, a, 1234 from t0; +connect con1,localhost,root,,; +connection con1; +begin; +explain +select * from t1 where kp1=2 for update; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 ref kp1 kp1 4 const # NULL +select * from t1 where kp1=2 for update; +kp1 kp2 a +2 3 1234 +2 5 1234 +2 7 1234 +connection default; +begin; +insert into t1 values (2, 9, 9999); +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.kp1 +delete from t1 where kp1=2 and kp2=5; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.kp1 +update t1 set kp1=333 where kp1=2 and kp2=3; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.kp1 +update t1 set kp1=2 where kp1=1 and kp2=8; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction: Timeout on index: test.t1.kp1 +rollback; +connection con1; +rollback; +disconnect con1; +connection default; +drop table t0,t1; +# +# Transaction isolation test +# +create table t1 (pk int primary key, a int) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3); +connect con1,localhost,root,,; +# TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; +pk a +1 1 +2 2 +3 3 +# TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=2222 where pk=2; +# TRX1: Now, make a change that would overwrite TRX2'x change and commit +connection con1; +update t1 set a=a+1 where pk=2; +commit; +# Examine the result: +# pk=2, a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) +# pk=2, a=3 means UPDATE in TRX1 silently overwrote TRX2 +# (and with key tracking, one would get an error on the second UPDATE) +connection default; +select * from t1; +pk a +1 1 +2 2223 +3 3 +disconnect con1; +connection default; +drop table t1; +# +# Same test as above, but check the range scan +# +create table t1 ( +pk int, +a int, +primary key (pk) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); +connect con1,localhost,root,,; +# TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; +pk a +6 6 +5 5 +4 4 +3 3 +2 2 +1 1 +# TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=2222 where pk between 3 and 5; +# TRX1: Now, make a change that would overwrite TRX2'x change and commit +connection con1; +update t1 set a=a+1 where pk between 3 and 5; +commit; +# Examine the result: +# pk={3,4,5} a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) +connection default; +select * from t1; +pk a +6 6 +5 2223 +4 2223 +3 2223 +2 2 +1 1 +disconnect con1; +connection default; +drop table t1; +# +# Same as above, but test SELECT FOR UPDATE. +# +create table t1 ( +pk int, +a int, +primary key (pk) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); +connect con1,localhost,root,,; +# TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; +pk a +6 6 +5 5 +4 4 +3 3 +2 2 +1 1 +# TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=222 where pk=2; +update t1 set a=333 where pk=3; +# TRX1: Check what select [FOR UPDATE] sees +connection con1; +select * from t1 where pk in (2,3); +pk a +2 2 +3 3 +select * from t1 where pk=2 for update; +pk a +2 222 +select * from t1 where pk=2; +pk a +2 2 +commit; +disconnect con1; +connection default; +drop table t1; +# +# Check that I_S.processlist.state is set correctly now. +# +create table t1( +pk int, +a int, +primary key(pk) comment 'rev:cf1' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3); +begin; +select * from t1 where pk=2 for update; +pk a +2 2 +connect con1,localhost,root,,; +begin; +set rocksdb_lock_wait_timeout=300; +select * from t1 where pk=2 for update; +connection default; +# Now, will wait until we see con1 have state="Waiting for row lock" +rollback; +connection con1; +pk a +2 2 +rollback; +disconnect con1; +connection default; +drop table t1; diff --git a/mysql-test/suite/rocksdb/t/range_locking.inc b/mysql-test/suite/rocksdb/t/range_locking.inc new file mode 100644 index 00000000000..9c826811695 --- /dev/null +++ b/mysql-test/suite/rocksdb/t/range_locking.inc @@ -0,0 +1,414 @@ +# +# Range locking tests. +# + +--source include/have_rocksdb.inc +--source suite/rocksdb/include/have_range_locking.inc + +--enable_connect_log + + +show variables like 'rocksdb_use_range_locking'; + +# Test 1: see that ranges are indeed lockied. + +eval create table t1 ( + pk int, + a int, + primary key (pk) comment '$pk_cf' +) engine=rocksdb; + +insert into t1 values +(10,10),(20,20),(30,30); + +connect (con1,localhost,root,,); +connect (con2,localhost,root,,); + +--echo ### Test: check that range lock inhibits a point lock +connection con1; +begin; +select * from t1 where pk between 5 and 25 for update; + +connection con2; +--error ER_LOCK_WAIT_TIMEOUT +insert into t1 values (15,15); + +connection con1; +rollback; + +--echo ## Test: check that range lock inhibits another range lock +--echo ## (It should not, but currently it does) +connection con1; +begin; +select * from t1 where pk between 5 and 25 for update; + +connection con2; +begin; +--error ER_LOCK_WAIT_TIMEOUT +select * from t1 where pk between 15 and 35 for update; +rollback; + +connection con1; +rollback; + +--echo ## Test: check that regular read does not get a range lock +connection con1; +begin; +select * from t1 where pk between 5 and 25; + +connection con2; +begin; +# This must not block +select * from t1 where pk between 15 and 35 for update; +rollback; + +connection con1; +rollback; + +--echo ## Test that locks are not released when a statement in the transaction +eval +create table t2 ( + pk int, + a int, + primary key (pk) comment '$pk_cf', + unique key(a) comment '$sk_cf' +) engine=rocksdb; + +insert into t2 values (1,1),(2,2); + +begin; +insert into t2 values (3,3); +--error ER_DUP_ENTRY +insert into t2 values (10,2); + +connection con2; +begin; +# This must time out: +--error ER_LOCK_WAIT_TIMEOUT +select * from t2 where pk=3 for update; + +rollback; +connection con1; +rollback; +drop table t2; + +# Cleanup +connection default; +disconnect con1; +disconnect con2; +drop table t1; + +--echo # +--echo # Test INFORMATION_SCHEMA.lock_info in range-locking mode +--echo # +eval +create table t1 ( + pk int, + a int, + primary key (pk) comment '$pk_cf' +) engine=rocksdb; + +insert into t1 values +(10,10),(20,20),(30,30); + +begin; +select * from t1 where pk=10 for update; + +select * from information_schema.rocksdb_locks; + +delete from t1 where pk between 25 and 40; +select * from information_schema.rocksdb_locks; + +rollback; +begin; +--echo # The following will show a range lock on 2-9 and also a point lock on 10. +--echo # This is how things currently work. +select * from t1 where pk between 2 and 9 for update; +select * from information_schema.rocksdb_locks; +rollback; + +drop table t1; + +--echo # +--echo # MDEV-18104: MyRocks-Gap-Lock: range locking bounds are incorrect for multi-part keys +--echo # + +create table t0(a int); +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); +eval +create table t1 ( + kp1 int not null, + kp2 int not null, + a int, + primary key(kp1, kp2) comment '$pk_cf' +) engine=rocksdb; + +insert into t1 select 1, a, 1234 from t0; +insert into t1 select 2, a, 1234 from t0; +insert into t1 select 3, a, 1234 from t0; + +connect (con1,localhost,root,,); +connection con1; + +begin; +select * from t1 where kp1=2 for update; + +connection default; +--echo # The lock on kp1=2 should inhibit the following INSERT: +--error ER_LOCK_WAIT_TIMEOUT +insert into t1 values ( 2,5,9999); +rollback; + +connection con1; +rollback; +connection default; +disconnect con1; +drop table t0,t1; + +--echo # +--echo # Test that locks on ranges on non-unique secondary keys inhibit +--echo # modifications of the contents of these ranges +--echo # + +create table t0(a int); +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); +eval +create table t1 ( + kp1 int not null, + kp2 int not null, + a int, + key(kp1, kp2) comment '$pk_cf' +) engine=rocksdb; + +insert into t1 select 1, a, 1234 from t0; +insert into t1 values (2, 3, 1234); +insert into t1 values (2, 5, 1234); +insert into t1 values (2, 7, 1234); +insert into t1 select 3, a, 1234 from t0; + +connect (con1,localhost,root,,); +connection con1; +begin; +--replace_column 9 # +explain +select * from t1 where kp1=2 for update; +select * from t1 where kp1=2 for update; + +connection default; +begin; +--error ER_LOCK_WAIT_TIMEOUT +insert into t1 values (2, 9, 9999); + +--error ER_LOCK_WAIT_TIMEOUT +delete from t1 where kp1=2 and kp2=5; + +# Update that "moves a row away" from the locked range +--error ER_LOCK_WAIT_TIMEOUT +update t1 set kp1=333 where kp1=2 and kp2=3; + +# Update that "moves a row into" the locked range +--error ER_LOCK_WAIT_TIMEOUT +update t1 set kp1=2 where kp1=1 and kp2=8; + +rollback; + +connection con1; +rollback; +disconnect con1; +connection default; +drop table t0,t1; + +--echo # +--echo # Transaction isolation test +--echo # + +create table t1 (pk int primary key, a int) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3); + +connect (con1,localhost,root,,); + +--echo # TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; + +--echo # TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=2222 where pk=2; + +--echo # TRX1: Now, make a change that would overwrite TRX2'x change and commit +connection con1; +update t1 set a=a+1 where pk=2; +commit; + +--echo # Examine the result: +--echo # pk=2, a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) +--echo # pk=2, a=3 means UPDATE in TRX1 silently overwrote TRX2 +--echo # (and with key tracking, one would get an error on the second UPDATE) +connection default; +select * from t1; + +disconnect con1; +connection default; +drop table t1; + +--echo # +--echo # Same test as above, but check the range scan +--echo # + +eval +create table t1 ( + pk int, + a int, + primary key (pk) comment '$pk_cf' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); + +connect (con1,localhost,root,,); + +--echo # TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; + +--echo # TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=2222 where pk between 3 and 5; + +--echo # TRX1: Now, make a change that would overwrite TRX2'x change and commit +connection con1; +update t1 set a=a+1 where pk between 3 and 5; +commit; + +--echo # Examine the result: +--echo # pk={3,4,5} a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) +connection default; +select * from t1; + +disconnect con1; +connection default; +drop table t1; + +--echo # +--echo # Same as above, but test SELECT FOR UPDATE. +--echo # +eval +create table t1 ( + pk int, + a int, + primary key (pk) comment '$pk_cf' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); + +connect (con1,localhost,root,,); + +--echo # TRX1: Start, Allocate a snapshot +connection con1; +begin; +select * from t1; + +--echo # TRX2: Make a change that TRX1 will not see +connection default; +update t1 set a=222 where pk=2; +update t1 set a=333 where pk=3; + +--echo # TRX1: Check what select [FOR UPDATE] sees +connection con1; +select * from t1 where pk in (2,3); +select * from t1 where pk=2 for update; +select * from t1 where pk=2; + +commit; + +disconnect con1; +connection default; +drop table t1; + +if (!$PK_USES_REVERSE_CF) { +--echo # +--echo # Another no-snapshot-checking test, this time for single-statement +--echo # transaction +--echo # +eval +create table t1 ( + pk int, + a int, + name varchar(16), + primary key(pk) comment '$pk_cf' +) engine=rocksdb; +insert into t1 values (1,1, 'row1'), (2,2,'row2'); + +connect (con1,localhost,root,,); +connection con1; +select get_lock('row1', 100); + +connection default; + +--echo # The following will read the first row (1,1,'row1'), and stop. + +send update t1 set a=a+100 where get_lock(name, 1000)=1; + +# Wait till the default connection has stopped: +connection con1; + +let $wait_condition= + SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE = "User lock" + AND INFO = "update t1 set a=a+100 where get_lock(name, 1000)=1"; +--source include/wait_condition.inc + +# Update the second row +update t1 set a=5 where pk=2; + +select release_lock('row1'); + +connection default; +reap; + +--echo # Look at the row with pk=2: +--echo # 2, 105, row2 - means the UPDATE was reading current data (Correct) +--echo # 2, 102, row - means the UPDATE read the snapshot (incorrect) +select * from t1; + +--echo # Try releasing both locks (in 5.6, we will be holding only the second one) +select release_lock(name) from t1; + +disconnect con1; +connection default; +drop table t1; +} + +--echo # +--echo # Check that I_S.processlist.state is set correctly now. +--echo # +eval +create table t1( + pk int, + a int, + primary key(pk) comment '$pk_cf' +) engine=rocksdb; +insert into t1 values (1,1),(2,2),(3,3); + +begin; +select * from t1 where pk=2 for update; + +--connect (con1,localhost,root,,) +begin; +set rocksdb_lock_wait_timeout=300; +send select * from t1 where pk=2 for update; + +connection default; +--echo # Now, will wait until we see con1 have state="Waiting for row lock" +let $wait_condition= + SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE = "Waiting for row lock" + AND INFO = "select * from t1 where pk=2 for update"; +--source include/wait_condition.inc + +rollback; +connection con1; +--reap +rollback; + +disconnect con1; +connection default; +drop table t1; + diff --git a/mysql-test/suite/rocksdb/t/range_locking.test b/mysql-test/suite/rocksdb/t/range_locking.test index df926a2920b..694b13215af 100644 --- a/mysql-test/suite/rocksdb/t/range_locking.test +++ b/mysql-test/suite/rocksdb/t/range_locking.test @@ -1,386 +1,6 @@ -# -# Range locking tests. -# ---source include/have_rocksdb.inc ---source suite/rocksdb/include/have_range_locking.inc ---enable_connect_log - - -show variables like 'rocksdb_use_range_locking'; - -# Test 1: see that ranges are indeed lockied. - -create table t1 ( - pk int primary key, - a int -) engine=rocksdb; - -insert into t1 values -(10,10),(20,20),(30,30); - -connect (con1,localhost,root,,); -connect (con2,localhost,root,,); - ---echo ### Test: check that range lock inhibits a point lock -connection con1; -begin; -select * from t1 where pk between 5 and 25 for update; - -connection con2; ---error ER_LOCK_WAIT_TIMEOUT -insert into t1 values (15,15); - -connection con1; -rollback; - ---echo ## Test: check that range lock inhibits another range lock ---echo ## (It should not, but currently it does) -connection con1; -begin; -select * from t1 where pk between 5 and 25 for update; - -connection con2; -begin; ---error ER_LOCK_WAIT_TIMEOUT -select * from t1 where pk between 15 and 35 for update; -rollback; - -connection con1; -rollback; - ---echo ## Test: check that regular read does not get a range lock -connection con1; -begin; -select * from t1 where pk between 5 and 25; - -connection con2; -begin; -# This must not block -select * from t1 where pk between 15 and 35 for update; -rollback; - -connection con1; -rollback; - ---echo ## Test that locks are not released when a statement in the transaction -create table t2 ( - pk int primary key, - a int, - unique key(a) -) engine=rocksdb; - -insert into t2 values (1,1),(2,2); - -begin; -insert into t2 values (3,3); ---error ER_DUP_ENTRY -insert into t2 values (10,2); - -connection con2; -begin; -# This must time out: ---error ER_LOCK_WAIT_TIMEOUT -select * from t2 where pk=3 for update; - -rollback; -connection con1; -rollback; -drop table t2; - -# Cleanup -connection default; -disconnect con1; -disconnect con2; -drop table t1; - ---echo # ---echo # Test INFORMATION_SCHEMA.lock_info in range-locking mode ---echo # -create table t1 ( - pk int primary key, - a int -) engine=rocksdb; - -insert into t1 values -(10,10),(20,20),(30,30); - -begin; -select * from t1 where pk=10 for update; - -select * from information_schema.rocksdb_locks; - -delete from t1 where pk between 25 and 40; -select * from information_schema.rocksdb_locks; - -rollback; -begin; ---echo # The following will show a range lock on 2-9 and also a point lock on 10. ---echo # This is how things currently work. -select * from t1 where pk between 2 and 9 for update; -select * from information_schema.rocksdb_locks; -rollback; - -drop table t1; - ---echo # ---echo # MDEV-18104: MyRocks-Gap-Lock: range locking bounds are incorrect for multi-part keys ---echo # - -create table t0(a int); -insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); -create table t1 ( - kp1 int not null, - kp2 int not null, - a int, - primary key(kp1, kp2) -) engine=rocksdb; - -insert into t1 select 1, a, 1234 from t0; -insert into t1 select 2, a, 1234 from t0; -insert into t1 select 3, a, 1234 from t0; - -connect (con1,localhost,root,,); -connection con1; - -begin; -select * from t1 where kp1=2 for update; - -connection default; ---echo # The lock on kp1=2 should inhibit the following INSERT: ---error ER_LOCK_WAIT_TIMEOUT -insert into t1 values ( 2,5,9999); -rollback; - -connection con1; -rollback; -connection default; -disconnect con1; -drop table t0,t1; - ---echo # ---echo # Test that locks on ranges on non-unique secondary keys inhibit ---echo # modifications of the contents of these ranges ---echo # - -create table t0(a int); -insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); -create table t1 ( - kp1 int not null, - kp2 int not null, - a int, - key(kp1, kp2) -) engine=rocksdb; - -insert into t1 select 1, a, 1234 from t0; -insert into t1 values (2, 3, 1234); -insert into t1 values (2, 5, 1234); -insert into t1 values (2, 7, 1234); -insert into t1 select 3, a, 1234 from t0; - -connect (con1,localhost,root,,); -connection con1; -begin; ---replace_column 9 # -explain -select * from t1 where kp1=2 for update; -select * from t1 where kp1=2 for update; - -connection default; -begin; ---error ER_LOCK_WAIT_TIMEOUT -insert into t1 values (2, 9, 9999); - ---error ER_LOCK_WAIT_TIMEOUT -delete from t1 where kp1=2 and kp2=5; - -# Update that "moves a row away" from the locked range ---error ER_LOCK_WAIT_TIMEOUT -update t1 set kp1=333 where kp1=2 and kp2=3; - -# Update that "moves a row into" the locked range ---error ER_LOCK_WAIT_TIMEOUT -update t1 set kp1=2 where kp1=1 and kp2=8; - -rollback; - -connection con1; -rollback; -disconnect con1; -connection default; -drop table t0,t1; - ---echo # ---echo # Transaction isolation test ---echo # - -create table t1 (pk int primary key, a int) engine=rocksdb; -insert into t1 values (1,1),(2,2),(3,3); - -connect (con1,localhost,root,,); - ---echo # TRX1: Start, Allocate a snapshot -connection con1; -begin; -select * from t1; - ---echo # TRX2: Make a change that TRX1 will not see -connection default; -update t1 set a=2222 where pk=2; - ---echo # TRX1: Now, make a change that would overwrite TRX2'x change and commit -connection con1; -update t1 set a=a+1 where pk=2; -commit; - ---echo # Examine the result: ---echo # pk=2, a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) ---echo # pk=2, a=3 means UPDATE in TRX1 silently overwrote TRX2 ---echo # (and with key tracking, one would get an error on the second UPDATE) -connection default; -select * from t1; - -disconnect con1; -connection default; -drop table t1; - ---echo # ---echo # Same test as above, but check the range scan ---echo # - -create table t1 (pk int primary key, a int) engine=rocksdb; -insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); - -connect (con1,localhost,root,,); - ---echo # TRX1: Start, Allocate a snapshot -connection con1; -begin; -select * from t1; - ---echo # TRX2: Make a change that TRX1 will not see -connection default; -update t1 set a=2222 where pk between 3 and 5; - ---echo # TRX1: Now, make a change that would overwrite TRX2'x change and commit -connection con1; -update t1 set a=a+1 where pk between 3 and 5; -commit; - ---echo # Examine the result: ---echo # pk={3,4,5} a=2223 means UPDATE in TRX1 used "read committed" (InnoDB-like isolation) -connection default; -select * from t1; - -disconnect con1; -connection default; -drop table t1; - ---echo # ---echo # Same as above, but test SELECT FOR UPDATE. ---echo # -create table t1 (pk int primary key, a int) engine=rocksdb; -insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6); - -connect (con1,localhost,root,,); - ---echo # TRX1: Start, Allocate a snapshot -connection con1; -begin; -select * from t1; - ---echo # TRX2: Make a change that TRX1 will not see -connection default; -update t1 set a=222 where pk=2; -update t1 set a=333 where pk=3; - ---echo # TRX1: Check what select [FOR UPDATE] sees -connection con1; -select * from t1 where pk in (2,3); -select * from t1 where pk=2 for update; -select * from t1 where pk=2; - -commit; - -disconnect con1; -connection default; -drop table t1; - ---echo # ---echo # Another no-snapshot-checking test, this time for single-statement ---echo # transaction ---echo # - -create table t1 (pk int primary key, a int, name varchar(16)) engine=rocksdb; -insert into t1 values (1,1, 'row1'), (2,2,'row2'); - -connect (con1,localhost,root,,); -connection con1; -select get_lock('row1', 100); - -connection default; - ---echo # The following will read the first row (1,1,'row1'), and stop. - -send update t1 set a=a+100 where get_lock(name, 1000)=1; - -# Wait till the default connection has stopped: -connection con1; - -let $wait_condition= - SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE = "User lock" - AND INFO = "update t1 set a=a+100 where get_lock(name, 1000)=1"; ---source include/wait_condition.inc - -# Update the second row -update t1 set a=5 where pk=2; - -select release_lock('row1'); - -connection default; -reap; - ---echo # Look at the row with pk=2: ---echo # 2, 105, row2 - means the UPDATE was reading current data (Correct) ---echo # 2, 102, row - means the UPDATE read the snapshot (incorrect) -select * from t1; - ---echo # Try releasing both locks (in 5.6, we will be holding only the second one) -select release_lock(name) from t1; - -disconnect con1; -connection default; -drop table t1; - - ---echo # ---echo # Check that I_S.processlist.state is set correctly now. ---echo # -create table t1(pk int primary key, a int) engine=rocksdb; -insert into t1 values (1,1),(2,2),(3,3); - -begin; -select * from t1 where pk=2 for update; - ---connect (con1,localhost,root,,) -begin; -set rocksdb_lock_wait_timeout=300; -send select * from t1 where pk=2 for update; - -connection default; ---echo # Now, will wait until we see con1 have state="Waiting for row lock" -let $wait_condition= - SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE = "Waiting for row lock" - AND INFO = "select * from t1 where pk=2 for update"; ---source include/wait_condition.inc - -rollback; -connection con1; ---reap -rollback; - -disconnect con1; -connection default; -drop table t1; +--let pk_cf=default +--let sk_cf=default +--source range_locking.inc diff --git a/mysql-test/suite/rocksdb/t/range_locking_rev_cf.test b/mysql-test/suite/rocksdb/t/range_locking_rev_cf.test new file mode 100644 index 00000000000..8b993764235 --- /dev/null +++ b/mysql-test/suite/rocksdb/t/range_locking_rev_cf.test @@ -0,0 +1,12 @@ +# +# Range locking tests. +# + +--source include/have_rocksdb.inc +--source suite/rocksdb/include/have_range_locking.inc + +--let pk_cf=rev:cf1 +--let PK_USES_REVERSE_CF=1 + +--source range_locking.inc + diff --git a/rocksdb b/rocksdb index 248acd10346..9af13f0e966 160000 --- a/rocksdb +++ b/rocksdb @@ -1 +1 @@ -Subproject commit 248acd10346428b078aed780183ffe7f9f3c6896 +Subproject commit 9af13f0e966171ef8688484b2da7fa576a1b4574