Andrew Kryczka

This doesn't seem to repro what the original issue is about, plus I tried changing the classpath to `options[numOptions++].optionString = "-Djava.class.path=.:rocksdbjni-8.9.1-linux64.jar";` and it worked ``` $ ./forktest java path: /usr/lib/jvm/java-8-openjdk-amd64...

Thanks for reporting. I think the most we can promise right now is making it explicitly unsupported, i.e., disallow range deletions when row cache is enabled. If you want to...

@ameya-deshmukh Sorry for the delay. Yes it's still up for grabs.

> removing /Wxxxx switches (where xxxx is a warning id indicated here) Where is "here"? Should there be a list of warnings we can't disable with accompanying reasons?

> What kind of scenarios that Rocksdb can produce such out-of-order keys? Some scenarios: the input files have out-of-order keys, memory corruption (either by RocksDB itself or the application corrupting...

A block stays in block cache until evicted by LRU. From the LOG: ``` "raw_key_size": 901728 ... "raw_value_size": 1561798 ``` So the uncompressed data size is only 1561798+901728 =~ 2.5MB....

> So even the expired entries from sst files are removed during compaction. The cache still holds the value until it evicts by the LRU Right, blocks from deleted files...

> Yes, but read happens from block cache right ? why there is a slowness in that . The layout of a sorted string table isn't the best for random...

Are you able to build without optimizations and rerun? A lot happens under `CheckConsistency()`, which makes it difficult to guess from that stack trace what causes the SIGSEGV.

Could you please provide the setting you have for `recycle_log_file_num`? Additionally, if you have the full contents of the OPTIONS file used to write the DB, that could potentially give...