Major - P3 While debugging WT-3199, I noticed a periodic failure:
WT_CURSOR.search: Failed lookup in bloom filter: WT_ROLLBACK: conflict between concurrent operations
Reproduces with this format configuration:
############################################ # RUN PARAMETERS ############################################ abort=0 alter=0 auto_throttle=0 backups=0 bitcnt=8 bloom=1 bloom_bit_count=17 bloom_hash_count=13 bloom_oldest=0 cache=60 checkpoints=1 checksum=uncompressed chunk_size=2 compaction=0 compression=snappy data_extend=0 data_source=lsm delete_pct=9 dictionary=1 direct_io=0 encryption=none evict_max=4 file_type=row-store firstfit=0 huffman_key=0 huffman_value=0 in_memory=0 insert_pct=28 internal_key_truncation=1 internal_page_max=11 isolation=random key_gap=18 key_max=122 key_min=21 leaf_page_max=12 leak_memory=0 logging=1 logging_archive=0 logging_compression=snappy logging_prealloc=0 long_running_txn=0 lsm_worker_threads=4 merge_max=4 mmap=1 ops=100000 prefix_compression=0 prefix_compression_min=1 read_pct=6 rebalance=1 repeat_data_pct=32 reverse=0 rows=100000 runs=100 salvage=1 split_pct=65 statistics=1 statistics_server=0 threads=22 timer=20 transaction-frequency=55 value_max=3051 value_min=1 verify=1 wiredtiger_config= write_pct=57 rebalance=1 ############################################
alexander.gorrod and michael.cahill commented:
> That's a bug. It means that the bloom filter and contents of the table it filters are out of sync
> Could we get that rollback because of a cache full condition?
> Yes - that’s possible (and a bit horrible). I’d be reluctant to completely remove the error message from that path, though I guess we could only log an error if WT_NOTFOUND is returned - that’s the surprising failure mode.