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