[MDEV-14562] rocksdb.bloomfilter failed in buildbot, results mismatch Created: 2017-12-04  Updated: 2018-05-14  Resolved: 2018-05-14

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - RocksDB
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.2.15

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None
Environment:

winx64


 Description   

http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/5959/steps/test/logs/stdio

rocksdb.bloomfilter                      w4 [ fail ]
 
        Test ended at 2017-12-03 13:09:54
 
 
 
CURRENT_TEST: rocksdb.bloomfilter
 
--- D:/winx64-packages/build/src/storage/rocksdb/mysql-test/rocksdb/r/bloomfilter.result	2017-12-03 12:05:22.000000000 +0000
 
+++ D:\winx64-packages\build\src\storage\rocksdb\mysql-test\rocksdb\r\bloomfilter.reject	2017-12-03 13:09:54.022511500 +0000
 
@@ -849,7 +849,7 @@
 
 10000
 
 call bloom_end();
 
 checked
 
-true
 
+false
 
 call bloom_start();
 
 select count(*) from t2;
 
 count(*)
 
 
 
mysqltest: Result length mismatch



 Comments   
Comment by Elena Stepanova [ 2018-04-08 ]

According to cross-reference, it was happening on 10.2 as well. Then it stopped for 2 months (maybe the test was disabled?) and now it re-appears on bb-10.2-mariarocks-merge. Thus, I'm adding 10.2 to affected versions.

Comment by Sergei Petrunia [ 2018-04-09 ]

Queries right before the difference:

create or replace table t1 (
 
id1 bigint not null,
 
id2 bigint not null,
 
id3 varchar(100) not null,
 
id4 int not null,
 
id5 int not null,
 
value bigint,
 
value2 varchar(100),
 
primary key (id1, id2, id3, id4) COMMENT 'rev:cf_short_prefix',
 
index id2 (id2) COMMENT 'rev:cf_short_prefix',
 
index id2_id1 (id2, id1) COMMENT 'rev:cf_short_prefix',
 
index id2_id3 (id2, id3) COMMENT 'rev:cf_short_prefix',
 
index id2_id4 (id2, id4) COMMENT 'rev:cf_short_prefix',
 
index id2_id3_id1_id4 (id2, id3, id1, id4) COMMENT 'rev:cf_short_prefix',
 
index id3_id2 (id3, id2) COMMENT 'rev:cf_short_prefix'
 
) engine=ROCKSDB;

...

insert t1
 
select (seq+9) div 10, (seq+4) div 5, (seq+4) div 5, seq, seq, 1000, "aaabbbccc"
 
  from seq_1_to_10000;
 
insert t2 select * from t1;
 
call bloom_start();
 
select count(*) from t1;
 
count(*)

A possible way this could be happening: INSERT has finished, but the table statistics was not updated yet. Then a different index isused for reading and thus bloomfitlter is not used.

Comment by Sergei Petrunia [ 2018-04-09 ]

OTOH, the column family settings are:

rocksdb_override_cf_options=
 
       cf_short_prefix={prefix_extractor=capped:4};
 
   rev:cf_short_prefix={prefix_extractor=capped:4};

bloom_end() checks if rocksdb_bloom_filter_prefix_checked > 0.

4 bytes are index-nr, so theoretically any table access should have checked the bloom filter (or perhaps there is a primary vs secondary or covering/non-covering index difference?)

Comment by Vladislav Vaintroub [ 2018-04-09 ]

elenst yes, it was disabled, by me, in the attached commits.

Generated at Thu Feb 08 08:14:33 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.