On 10.2, there is also this failure (the cause is most likely that DDL_DROP_INDEX_ONGOING is finished before the query finishes):
http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/6487/steps/test/logs/stdio
rocksdb.information_schema w4 [ fail ]
|
Test ended at 2018-01-12 14:38:10
|
|
CURRENT_TEST: rocksdb.information_schema
|
--- D:/winx64-packages/build/src/storage/rocksdb/mysql-test/rocksdb/r/information_schema.result 2018-01-12 13:52:18.000000000 +0000
|
+++ D:\winx64-packages\build\src\storage\rocksdb\mysql-test\rocksdb\r\information_schema.reject 2018-01-12 14:38:10.199026800 +0000
|
@@ -11,7 +11,7 @@
|
DDL_DROP_INDEX_ONGOING cf_id:0,index_id:max_index_id
|
select count(*) from INFORMATION_SCHEMA.ROCKSDB_GLOBAL_INFO;
|
count(*)
|
-4
|
+3
|
select VALUE into @keysIn from INFORMATION_SCHEMA.ROCKSDB_COMPACTION_STATS where CF_NAME = 'default' and LEVEL = 'Sum' and TYPE = 'KeyIn';
|
CREATE TABLE t1 (i1 INT, i2 INT, PRIMARY KEY (i1)) ENGINE = ROCKSDB;
|
INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3);
|
|
mysqltest: Result content mismatch
|
Re-try run causes a different kind of failure:
rocksdb.information_schema w4 [ retry-fail ]
|
Test ended at 2018-01-12 14:38:15
|
|
CURRENT_TEST: rocksdb.information_schema
|
--- D:/winx64-packages/build/src/storage/rocksdb/mysql-test/rocksdb/r/information_schema.result 2018-01-12 13:52:18.000000000 +0000
|
+++ D:\winx64-packages\build\src\storage\rocksdb\mysql-test\rocksdb\r\information_schema.reject 2018-01-12 14:38:15.132863500 +0000
|
@@ -8,10 +8,21 @@
|
MAX_INDEX_ID MAX_INDEX_ID max_index_id
|
CF_FLAGS 0 default [0]
|
CF_FLAGS 1 __system__ [0]
|
+CF_FLAGS 2 cf_a [0]
|
+CF_FLAGS 3 cf_b [0]
|
+CF_FLAGS 4 cf_c [0]
|
+CF_FLAGS 5 rev:cf_d [1]
|
DDL_DROP_INDEX_ONGOING cf_id:0,index_id:max_index_id
|
+DDL_DROP_INDEX_ONGOING cf_id:0,index_id:257
|
+DDL_DROP_INDEX_ONGOING cf_id:4,index_id:262
|
+DDL_DROP_INDEX_ONGOING cf_id:2,index_id:260
|
+DDL_DROP_INDEX_ONGOING cf_id:0,index_id:258
|
+DDL_DROP_INDEX_ONGOING cf_id:0,index_id:259
|
+DDL_DROP_INDEX_ONGOING cf_id:5,index_id:263
|
+DDL_DROP_INDEX_ONGOING cf_id:3,index_id:261
|
It seems the test is re-ran on the same datadir, and that causes it to fail as it is not suitable for running on a non-clean data directory (why does it run on a clean datadir to begin with? The outcome of discussion on Slack is that it is by chance and not by intent?)
The interesting part is here:
-BINLOG FILE master-bin.000001
-BINLOG POS 1066
-BINLOG GTID uuid:5
-MAX_INDEX_ID MAX_INDEX_ID max_index_id
+MAX_INDEX_ID MAX_INDEX_ID 256