- 11 4月, 2020 1 次提交
-
-
由 Huisheng Liu 提交于
Summary: (Based on Yanqin's idea) Add a new field in readoptions as lower timestamp bound for iterator. When the parameter is not supplied (nullptr), the iterator returns the latest visible version of a record. When it is supplied, the existing timestamp field is the upper bound. Together the two serves as a bounded time window. The iterator returns all versions of a record falling in the window. SeekRandom perf test (10 minutes) on the same development machine ram drive with the same DB data shows no regression (within marge of error). The test is adapted from https://github.com/facebook/rocksdb/wiki/RocksDB-In-Memory-Workload-Performance-Benchmarks. base line (commit e860f884): seekrandom : 7.836 micros/op 4082449 ops/sec; (0 of 73481999 found) This PR: seekrandom : 7.764 micros/op 4120935 ops/sec; (0 of 71303999 found) db_bench --db=r:\rocksdb.github --num_levels=6 --key_size=20 --prefix_size=20 --keys_per_prefix=0 --value_size=100 --cache_size=2147483648 --cache_numshardbits=6 --compression_type=none --compression_ratio=1 --min_level_to_compress=-1 --disable_seek_compaction=1 --hard_rate_limit=2 --write_buffer_size=134217728 --max_write_buffer_number=2 --level0_file_num_compaction_trigger=8 --target_file_size_base=134217728 --max_bytes_for_level_base=1073741824 --disable_wal=0 --wal_dir=r:\rocksdb.github\WAL_LOG --sync=0 --verify_checksum=1 --statistics=0 --stats_per_interval=0 --stats_interval=1048576 --histogram=0 --use_plain_table=1 --open_files=-1 --memtablerep=prefix_hash --bloom_bits=10 --bloom_locality=1 --duration=600 --benchmarks=seekrandom --use_existing_db=1 --num=25000000 --threads=32 --allow_concurrent_memtable_write=0 Pull Request resolved: https://github.com/facebook/rocksdb/pull/6544 Reviewed By: ltamasi Differential Revision: D20844069 Pulled By: riversand963 fbshipit-source-id: d97f2bf38a323c8c6a68db213b2d3c694b1c1f74
-
- 10 4月, 2020 4 次提交
-
-
由 Luca Giacchino 提交于
Summary: New memory technologies are being developed by various hardware vendors (Intel DCPMM is one such technology currently available). These new memory types require different libraries for allocation and management (such as PMDK and memkind). The high capacities available make it possible to provision large caches (up to several TBs in size), beyond what is achievable with DRAM. The new allocator provided in this PR uses the memkind library to allocate memory on different media. **Performance** We tested the new allocator using db_bench. - For each test, we vary the size of the block cache (relative to the size of the uncompressed data in the database). - The database is filled sequentially. Throughput is then measured with a readrandom benchmark. - We use a uniform distribution as a worst-case scenario. The plot shows throughput (ops/s) relative to a configuration with no block cache and default allocator. For all tests, p99 latency is below 500 us. ![image](https://user-images.githubusercontent.com/26400080/71108594-42479100-2178-11ea-8231-8a775bbc92db.png) **Changes** - Add MemkindKmemAllocator - Add --use_cache_memkind_kmem_allocator db_bench option (to create an LRU block cache with the new allocator) - Add detection of memkind library with KMEM DAX support - Add test for MemkindKmemAllocator **Minimum Requirements** - kernel 5.3.12 - ndctl v67 - https://github.com/pmem/ndctl - memkind v1.10.0 - https://github.com/memkind/memkind **Memory Configuration** The allocator uses the MEMKIND_DAX_KMEM memory kind. Follow the instructions on[ memkind’s GitHub page](https://github.com/memkind/memkind) to set up NVDIMM memory accordingly. Note on memory allocation with NVDIMM memory exposed as system memory. - The MemkindKmemAllocator will only allocate from NVDIMM memory (using memkind_malloc with MEMKIND_DAX_KMEM kind). - The default allocator is not restricted to RAM by default. Based on NUMA node latency, the kernel should allocate from local RAM preferentially, but it’s a kernel decision. numactl --preferred/--membind can be used to allocate preferentially/exclusively from the local RAM node. **Usage** When creating an LRU cache, pass a MemkindKmemAllocator object as argument. For example (replace capacity with the desired value in bytes): ``` #include "rocksdb/cache.h" #include "memory/memkind_kmem_allocator.h" NewLRUCache( capacity /*size_t*/, 6 /*cache_numshardbits*/, false /*strict_capacity_limit*/, false /*cache_high_pri_pool_ratio*/, std::make_shared<MemkindKmemAllocator>()); ``` Refer to [RocksDB’s block cache documentation](https://github.com/facebook/rocksdb/wiki/Block-Cache) to assign the LRU cache as block cache for a database. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6214 Reviewed By: cheng-chang Differential Revision: D19292435 fbshipit-source-id: 7202f47b769e7722b539c86c2ffd669f64d7b4e1
-
由 Peter Dillinger 提交于
Summary: Until Travis gets its act together (https://github.com/facebook/rocksdb/issues/6653) Pull Request resolved: https://github.com/facebook/rocksdb/pull/6682 Test Plan: CI Reviewed By: riversand963 Differential Revision: D20948865 Pulled By: pdillinger fbshipit-source-id: 215de523c91a83d2a159f466b853e700c925ba4f
-
由 sdong 提交于
Summary: https://github.com/facebook/rocksdb/pull/6668 added some new test code but it has a risk of memory corruption. Fix it Pull Request resolved: https://github.com/facebook/rocksdb/pull/6676 Test Plan: Run the test under ASAN and see it passes. Reviewed By: ajkr Differential Revision: D20937108 fbshipit-source-id: 22cc96bb02030df0a37a02e67a2cc37ca31ba22d
-
由 Cheng Chang 提交于
Summary: Although these optimizations are not user facing, still feel it's valuable to call out in HISTORY. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6679 Test Plan: no need Reviewed By: zhichao-cao Differential Revision: D20945916 Pulled By: cheng-chang fbshipit-source-id: f3e790c07f3bcc4a8a74246c4fa232800ddd4438
-
- 09 4月, 2020 6 次提交
-
-
由 Yi Wu 提交于
Summary: On reading an ingested SST file, `DataBlockIter` will replace seqno encoded in a key with global seqno. However, if the original seqno was part of the prefix used for the next key, the global seqno is by mistake used as part of the prefix to construct the next key, causing wrong result being returned. Although at this point it is only software error while data in the file is not corrupted, the issue can further cause compaction output out of order and corrupted result when the ingested SST participated in compaction. Fixing the issue by save the actual seqno and restore it before the key being used as prefix to construct next key. The unit test is by Little-Wallace from https://github.com/facebook/rocksdb/issues/6666. Fixing https://github.com/facebook/rocksdb/issues/6666. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6669 Test Plan: New unit test Signed-off-by: NYi Wu <yiwu@pingcap.com> Reviewed By: cheng-chang Differential Revision: D20931808 Pulled By: ajkr fbshipit-source-id: f01959c35d6a493954dca981663766c7a5a9e8ab
-
由 Cheng Chang 提交于
Summary: When aligned_buf is provided, the result slice's starting address should take offset advance into account. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6672 Test Plan: make check Reviewed By: anand1976 Differential Revision: D20934198 Pulled By: cheng-chang fbshipit-source-id: c3475c9c132b92c50d8c7c399fca2e9e76870803
-
由 Yi Wu 提交于
Summary: Source code path in info log is not truncated to the correct length. Fixing it. Pull Request resolved: https://github.com/facebook/rocksdb/pull/5824 Test Plan: Build and run db_bench. Before: ``` 2019/09/18-21:32:34.631181 7fdd42df6700 [_impl/db_impl_write.cc:1654] [default] New memtable created with log file: https://github.com/facebook/rocksdb/issues/9. Immutable memtables: 0. ``` After: ``` 2019/09/18-21:36:09.226532 7f141b5f6700 [/db_impl/db_impl_write.cc:1654] [default] New memtable created with log file: https://github.com/facebook/rocksdb/issues/9. Immutable memtables: 0. ``` Reviewed By: cheng-chang Differential Revision: D17511851 fbshipit-source-id: b2f92c85ce78726c27b7e0e736657fe2f983513e
-
由 sdong 提交于
Summary: … to CFOptions https://github.com/facebook/rocksdb/pull/6615 made several compression related options dynamically changeable. They are moved to MutableCFOptions. However, they are not copied back to ColumnFamilyOptions, so the changed values are not written to option files and for some other uses. Fix it by copying them back. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6668 Test Plan: Add a unit test to make sure that when a MutableCFOptions is converted to CFOptions and back to MutableCFOptions, they stay the same. This test would fail without the fix. Reviewed By: ajkr Differential Revision: D20923999 fbshipit-source-id: c3bccd6923b00d677764e2269bed6a95ad7ed780
-
由 CaixinGong 提交于
Summary: This commit is fixing a bug that readrandom test returns many NotFound in db_bench from Version 6.2. Pull Request resolved: https://github.com/facebook/rocksdb/issues/6664 Pull Request resolved: https://github.com/facebook/rocksdb/pull/6665 Reviewed By: cheng-chang Differential Revision: D20911298 Pulled By: ajkr fbshipit-source-id: c2658d4dbb35798ccbf67dff6e64923fb731ef81
-
由 Cheng Chang 提交于
Summary: Although there are tests related to locking in transaction_test, this new test directly tests against TransactionLockMgr. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6599 Test Plan: make transaction_lock_mgr_test && ./transaction_lock_mgr_test Reviewed By: lth Differential Revision: D20673749 Pulled By: cheng-chang fbshipit-source-id: 1fa4a13218e68d785f5a99924556751a8c5c0f31
-
- 08 4月, 2020 6 次提交
-
-
由 Tomas Kolda 提交于
Summary: This change is fixing a crash happening in getApproximateSizes JNI implementation. It also reenables Java test that was crashing most likelly because if this bug. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6652 Reviewed By: cheng-chang Differential Revision: D20874865 Pulled By: pdillinger fbshipit-source-id: da95516f15e5df2efe1a4e5690a2ce172cb53f87
-
由 Sahib Pandori 提交于
Summary: Adding a Java API for rocksdb::CancelAllBackgroundWork() so that the user can call this (when required) before closing the DB. This is to **prevent the crashes when manual compaction is running and the user decides to close the DB**. Calling CancelAllBackgroundWork() seems to be the recommended way to make sure that it's safe to close the DB (according to RocksDB FAQ: https://github.com/facebook/rocksdb/wiki/RocksDB-FAQ#basic-readwrite). Pull Request resolved: https://github.com/facebook/rocksdb/pull/6657 Reviewed By: cheng-chang Differential Revision: D20896395 Pulled By: pdillinger fbshipit-source-id: 8a8208c10093db09bd35db9af362211897870d96
-
由 Peter Dillinger 提交于
Summary: Example compiler output, from OSX TEST_GROUP=3: db/flush_job_test.cc:185:7: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] kInvalidBlobFileNumber, 5, 103, 17, 102, 101}; Apparently permitted in newer version, but worth working around. https://stackoverflow.com/questions/31555584/why-is-clang-warning-suggest-braces-around-initialization-of-subobject-wmis Pull Request resolved: https://github.com/facebook/rocksdb/pull/6662 Test Plan: CI (temporarily including OSX TEST_GROUP=3 in Travis) Reviewed By: ltamasi Differential Revision: D20901009 Pulled By: pdillinger fbshipit-source-id: 5338878613b5725e5d632c8858904de467dc4692
-
由 Kirill Abrosimov 提交于
Summary: Few functions from options added to C-api Pull Request resolved: https://github.com/facebook/rocksdb/pull/5630 Reviewed By: anand1976 Differential Revision: D20896731 Pulled By: ltamasi fbshipit-source-id: e4215a58b3c2429ec44e3f0d0381cbf86700fb14
-
由 anand76 提交于
Summary: It was incorrectly counting time even for blocks that didn't need decompression. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6658 Test Plan: make check Reviewed By: ajkr Differential Revision: D20883522 Pulled By: anand1976 fbshipit-source-id: 33c9c4683f54cad150ab260a69e3ef8aa9aff76a
-
由 Sagar Vemuri 提交于
Summary: Adding a simple timer support to schedule work at a fixed time. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6543 Test Plan: TODO: clean up the unit tests, and make them better. Reviewed By: siying Differential Revision: D20465390 Pulled By: sagar0 fbshipit-source-id: cba143f70b6339863e1d0f8b8bf92e51c2b3d678
-
- 07 4月, 2020 2 次提交
-
-
由 Steven Fackler 提交于
Summary: The raw key bytes are currently dumped directly into the log messages, which is not ideal if the keys aren't ASCII strings. Null bytes in particular can cut off bits of the message early. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6616 Reviewed By: ajkr Differential Revision: D20879218 Pulled By: anand1976 fbshipit-source-id: 825a20715fe6d8012c0163c6e7b8159f7926a1a7
-
由 Istvan 提交于
Summary: Updating build script for CentOS 7 Pull Request resolved: https://github.com/facebook/rocksdb/pull/6617 Reviewed By: riversand963 Differential Revision: D20879268 Pulled By: anand1976 fbshipit-source-id: 414b99e39cd77ba31373ff7aff50121d78a93d1c
-
- 05 4月, 2020 1 次提交
-
-
由 Peter Dillinger 提交于
Summary: When Travis times out, it's hard to determine whether the last executing thing took an excessively long time or the sum of all the work just exceeded the time limit. This change inserts some timestamps in the output that should make this easier to determine. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6643 Test Plan: CI (Travis mostly) Reviewed By: anand1976 Differential Revision: D20843901 Pulled By: pdillinger fbshipit-source-id: e7aae5434b0c609931feddf238ce4355964488b7
-
- 04 4月, 2020 5 次提交
-
-
由 sdong 提交于
Summary: https://github.com/facebook/rocksdb/pull/6262 causes CLANG analyze to complain. Add assertion to suppress the warning. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6641 Test Plan: Run "clang analyze" and make sure it passes. Reviewed By: anand1976 Differential Revision: D20841722 fbshipit-source-id: 5fa6e0c5cfe7a822214c9b898a408df59d4fd2cd
-
由 Andrew Kryczka 提交于
Summary: as titled Pull Request resolved: https://github.com/facebook/rocksdb/pull/6642 Test Plan: ``` $ EXTRA_CXXFLAGS="-DNPERF_CONTEXT" DEBUG_LEVEL=0 make -j48 db_bench ``` Reviewed By: riversand963 Differential Revision: D20842313 Pulled By: ajkr fbshipit-source-id: a830cad312ca681591f06749242279503b101df2
-
由 mrambacher 提交于
Summary: This is a predecessor to the Configurable PR. This change moves the OptionTypeInfo maps closer to where they will be used. When the Configurable changes are adopted, these values will become static and not associated with the OptionsHelper. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6198 Reviewed By: siying Differential Revision: D20778108 Pulled By: zhichao-cao fbshipit-source-id: a9f85fc73bc53503656e1958ecc1e764052fd1aa
-
由 Peter Dillinger 提交于
Summary: I suspect LRUCache could use some optimization, and to support such an effort, a good benchmarking tool is needed. The existing cache_bench was heavily skewed toward insertion and lookup misses, and did not saturate memory with other work. This change should improve those things to better resemble a real workload. (All below using clang compiler, for some consistency, but not necessarily same version and settings.) The real workload is from production MySQL on RocksDB, filtering stacks containing "LRU", "ShardedCache" or "CacheShard." Lookup inclusive: 66% Insert inclusive: 17% Release inclusive: 15% An alternate simulated workload is MySQL running a LinkBench read test: Lookup inclusive: 54% Insert inclusive: 24% Release inclusive: 21% cache_bench default settings, prior to this change: Lookup inclusive: 35.8% Insert inclusive: 63.6% Release inclusive: 0% cache_bench after this change (intended as somewhat "tighter" workload than average production, more like LinkBench): Lookup inclusive: 52% Insert inclusive: 20% Release inclusive: 26% And top exclusive stacks (portion of stack samples as filtered above): Production MySQL: LRUHandleTable::FindPointer: 25.3% rocksdb::operator==: 15.1% <-- Slice == LRUCacheShard::LRU_Remove: 13.8% ShardedCache::Lookup: 8.9% __pthread_mutex_lock: 7.1% LRUCacheShard::LRU_Insert: 6.3% MurmurHash64A: 4.8% <-- Since upgraded to XXH3p ... Old cache_bench: LRUHandleTable::FindPointer: 23.6% __pthread_mutex_lock: 15.0% __pthread_mutex_unlock_usercnt: 11.7% __lll_lock_wait: 8.6% __lll_unlock_wake: 6.8% LRUCacheShard::LRU_Insert: 6.0% ShardedCache::Lookup: 4.4% LRUCacheShard::LRU_Remove: 2.8% ... rocksdb::operator==: 0.2% <-- Slice == ... New cache_bench: LRUHandleTable::FindPointer: 22.8% __pthread_mutex_unlock_usercnt: 14.3% rocksdb::operator==: 10.5% <-- Slice == LRUCacheShard::LRU_Insert: 9.0% __pthread_mutex_lock: 5.9% LRUCacheShard::LRU_Remove: 5.0% ... ShardedCache::Lookup: 2.9% ... So there's a bit more lock contention in the benchmark than in production, but otherwise looks similar enough to me. At least it's a big improvement over the existing code. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6629 Test Plan: No production code changes, ran cache_bench with ASAN Reviewed By: ltamasi Differential Revision: D20824318 Pulled By: pdillinger fbshipit-source-id: 6f8dc5891ead0f87edbed3a615ecd5289d9abe12
-
由 Burton Li 提交于
Summary: 1. stats_history_test: one slice of stats history is 12526 Bytes, which is greater than original assumption. ![image](https://user-images.githubusercontent.com/17753898/77381970-5a611a80-6d3c-11ea-9d64-59d2e3c04f79.png) 2. table_test: in VerifyBlockAccessTrace function, release trace reader before delete trace file. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6579 Reviewed By: siying Differential Revision: D20767373 Pulled By: pdillinger fbshipit-source-id: e8647d665cbe83a3f5429639c6219b50c0912124
-
- 03 4月, 2020 6 次提交
-
-
由 Zhichao Cao 提交于
Summary: In CompactionManifestWriteRetryableError in error_handler_fs_test, the manifest write of flush should pass with no fs error. After flush, fs is set to error status and the manifest write of compaction should fail due to the IO Error. Currently, the manifest write of flush is not synced with the compaction in order, which might cause manifest write fails, which will cause test failure. Fixed by adding the LoadDependency of sync-point after flush and before compaction. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6637 Test Plan: pass error_hanlder_fs_tes. Pass make asan_check Reviewed By: anand1976 Differential Revision: D20826969 Pulled By: zhichao-cao fbshipit-source-id: fb2e702caa19bd63c82570320536b7acda870ff1
-
由 anand76 提交于
Summary: This failure was introduced in https://github.com/facebook/rocksdb/issues/6262 Pull Request resolved: https://github.com/facebook/rocksdb/pull/6635 Reviewed By: siying Differential Revision: D20822602 Pulled By: anand1976 fbshipit-source-id: 96b316816cce6b95b092a7fc46ea968ed6ba8809
-
由 sdong 提交于
Summary: With https://github.com/facebook/rocksdb/issues/6262, TSAN complains about data race of some variables. Those variables are used to estimate file size and are accessed in writer and background threads. Since file size estimation doesn't have to be 100% accurate, we make some variables atomic and use relaxed memory order. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6636 Test Plan: Run all tests with TSAN. Reviewed By: anand1976 Differential Revision: D20820635 fbshipit-source-id: 1ea45ff38be15e33674ffe06b7d42fc9fe161ea5
-
由 Zhichao Cao 提交于
Summary: Remove redundant description in HISTORY no code change Pull Request resolved: https://github.com/facebook/rocksdb/pull/6627 Test Plan: make check Reviewed By: anand1976 Differential Revision: D20797269 Pulled By: zhichao-cao fbshipit-source-id: dee4c9a22f6d241c985f250c0f11bfaa9198f4c1
-
由 Ziyue Yang 提交于
Summary: With https://github.com/facebook/rocksdb/issues/6262, UBSAN fails with "division by zero": [ RUN ] Timestamp/DBBasicTestWithTimestampCompressionSettings.PutAndGetWithCompaction/3 internal_repo_rocksdb/repo/table/block_based/block_based_table_builder.cc:1066:39: runtime error: division by zero #0 0x7ffb3117b071 in rocksdb::BlockBasedTableBuilder::WriteRawBlock(rocksdb::Slice const&, rocksdb::CompressionType, rocksdb::BlockHandle*, bool) internal_repo_rocksdb/repo/table/block_based/block_based_table_builder.cc:1066 https://github.com/facebook/rocksdb/issues/1 0x7ffb311775e1 in rocksdb::BlockBasedTableBuilder::WriteBlock(rocksdb::Slice const&, rocksdb::BlockHandle*, bool) internal_repo_rocksdb/repo/table/block_based/block_based_table_builder.cc:848 https://github.com/facebook/rocksdb/issues/2 0x7ffb311771a2 in rocksdb::BlockBasedTableBuilder::WriteBlock(rocksdb::BlockBuilder*, rocksdb::BlockHandle*, bool) internal_repo_rocksdb/repo/table/block_based/block_based_table_builder.cc:832 This is caused by not returning immediately after CompressAndVerifyBlock call in WriteBlock when rep_->status == kBuffered. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6633 Test Plan: Run all existing test. Reviewed By: anand1976 Differential Revision: D20808366 fbshipit-source-id: 09f24b7c0fbaf4c7a8fc48cac61fa6fcb9b85811
-
由 Levi Tamasi 提交于
Summary: Does what it says on the can. Similarly to table files, we need to re-persist the metadata of live blob files whenever a new manifest file is opened. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6630 Test Plan: `make check` Reviewed By: riversand963 Differential Revision: D20802126 Pulled By: ltamasi fbshipit-source-id: 5738692d898790293bf09d66e9997369bbf89566
-
- 02 4月, 2020 5 次提交
-
-
由 Yi Wu 提交于
Summary: Add `encrypt_data_time` and `decrypt_data_time` perf_context counters to time encryption/decryption time when `EnvEncryption` is enabled. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6596 Test Plan: CI Reviewed By: anand1976 Differential Revision: D20678617 fbshipit-source-id: 7b57536143aa38509cde011f704de33382169e07
-
由 Ziyue Yang 提交于
Summary: This PR adds support for pipelined & parallel compression optimization for `BlockBasedTableBuilder`. This optimization makes block building, block compression and block appending a pipeline, and uses multiple threads to accelerate block compression. Users can set `CompressionOptions::parallel_threads` greater than 1 to enable compression parallelism. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6262 Reviewed By: ajkr Differential Revision: D20651306 fbshipit-source-id: 62125590a9c15b6d9071def9dc72589c1696a4cb
-
由 Sylvain Oliver 提交于
Summary: Compilation of rocksdb fails because -lpthread flag is needed by gtest **Before modification** : /usr/bin/c++ -W -Wextra -Wall -Wsign-compare -Wshadow -Wno-unused-parameter -Wno-unused-variable -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-strict-aliasing -std=c++11 -march=native -Werror -fno-builtin-memcmp -g -DROCKSDB_USE_RTTI CMakeFiles/table_reader_bench.dir/table/table_reader_bench.cc.o -o table_reader_bench -Wl,-rpath,/develop/src/rocksdb/build librocksdb.so.6.8.0 libtestharness.a /usr/lib/x86_64-linux-gnu/libgflags.so -lpthread third-party/gtest-1.8.1/fused-src/gtest/libgtest.a **After modification** : /usr/bin/c++ -W -Wextra -Wall -Wsign-compare -Wshadow -Wno-unused-parameter -Wno-unused-variable -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-strict-aliasing -std=c++11 -march=native -Werror -fno-builtin-memcmp -g -DROCKSDB_USE_RTTI CMakeFiles/table_reader_bench.dir/table/table_reader_bench.cc.o -o table_reader_bench -Wl,-rpath,/develop/src/rocksdb/build librocksdb.so.6.8.0 libtestharness.a /usr/lib/x86_64-linux-gnu/libgflags.so third-party/gtest-1.8.1/fused-src/gtest/libgtest.a -lpthread Pull Request resolved: https://github.com/facebook/rocksdb/pull/6572 Reviewed By: anand1976 Differential Revision: D20789059 Pulled By: ajkr fbshipit-source-id: 97329f14b9044b12c8a415da3d5f27b256ff8ff7
-
由 sdong 提交于
Summary: https://github.com/facebook/rocksdb/issues/6247 reports that when write buffer manager fails to insert the dummy entry to block cache, null pointer is still stored and used to release the handle and cause corruption. Fix the bug by not releasing it with null handle. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6619 Test Plan: Add a unit test that fails without the fix. Reviewed By: ajkr Differential Revision: D20776769 fbshipit-source-id: 4127fbd9f295a0a3e45774746ffcd91f939f6287
-
由 Yanqin Jin 提交于
Summary: As title. https://github.com/facebook/rocksdb/issues/6612 caused clang analyze to fail with the error: ``` db/compaction/compaction_picker_fifo.cc:105:39: warning: Called C++ object pointer is null cf_name.c_str(), f->fd.GetNumber(), creation_time); ^~~~~~~~~~~~~~~~~ ./logging/logging.h:59:36: note: expanded from macro 'ROCKS_LOG_BUFFER' ##__VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. ``` Test Plan (devserver): USE_CLANG=1 make analyze Pull Request resolved: https://github.com/facebook/rocksdb/pull/6622 Reviewed By: ltamasi Differential Revision: D20787407 Pulled By: riversand963 fbshipit-source-id: a5de4910cc1aa0d3481a73ec114578925bfd63f7
-
- 01 4月, 2020 3 次提交
-
-
由 Levi Tamasi 提交于
Summary: Revert "Use function objects as deleters in the block cache (https://github.com/facebook/rocksdb/issues/6545)" This reverts commit 6301dbe7. Revert "Call out the cache deleter related interface change in HISTORY.md (https://github.com/facebook/rocksdb/issues/6606)" This reverts commit 3a35542f. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6620 Test Plan: `make check` Reviewed By: zhichao-cao Differential Revision: D20773311 Pulled By: ltamasi fbshipit-source-id: 7637a761f718f323ef0e7da959462e8fb06e7a2b
-
由 sdong 提交于
Make options.bottommost_compression, compression_opts and bottommost_compression_opts dynamically changeable. (#6615) Summary: These three options should be made dynamically changeable. Simply add them to MutableCFOptions and made the change. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6615 Test Plan: Add a unit test to make sure that SetOptions() can change the options. Reviewed By: riversand963 Differential Revision: D20755951 fbshipit-source-id: 8165f4fd7a7a665cc7fb049698935022a5d2e7ff
-
由 Andrew Gallagher 提交于
Summary: Add `nothrow` attribute to match declarations in jemalloc. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6613 Reviewed By: igorsugak Differential Revision: D20749490 fbshipit-source-id: 9ac8df27f7b4268f27b32b130c23ce8a1f772b3a
-
- 31 3月, 2020 1 次提交
-
-
由 Yanqin Jin 提交于
Summary: For FIFO compaction, we use flush time instead of oldest key time as the creation time. This is to prevent FIFO compaction dropping files whose oldest key time is older than TTL but which has newer keys than TTL. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6612 Test Plan: make check Reviewed By: siying Differential Revision: D20748217 Pulled By: riversand963 fbshipit-source-id: 3f7b00a847020760537cdddd12f6fe039e5bc663
-