1. 16 1月, 2020 2 次提交
    • L
      Access Maven Central over HTTPS (#6301) · b7f1b3e5
      Levi Tamasi 提交于
      Summary:
      As of 1/15/2020, Maven Central does not support plain HTTP. Because of
      this, our Travis and AppVeyor builds have started failing during the
      assertj download step. This patch will hopefully fix these issues.
      
      See https://blog.sonatype.com/central-repository-moving-to-https
      for more info.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6301
      
      Test Plan:
      Will monitor the builds. ("I don't always test my changes but when I do,
      I do it in production.")
      
      Differential Revision: D19422923
      
      Pulled By: ltamasi
      
      fbshipit-source-id: 76f9a8564a5b66ddc721d705f9cbfc736bf7a97d
      b7f1b3e5
    • S
      Fix kHashSearch bug with SeekForPrev (#6297) · d2b4d42d
      sdong 提交于
      Summary:
      When prefix is enabled the expected behavior when the prefix of the target does not exist is for Seek is to seek to any key larger than target and SeekToPrev to any key less than the target.
      Currently. the prefix index (kHashSearch) returns OK status but sets Invalid() to indicate two cases: a prefix of the searched key does not exist, ii) the key is beyond the range of the keys in SST file. The SeekForPrev implementation in BlockBasedTable thus does not have enough information to know when it should set the index key to first (to return a key smaller than target). The patch fixes that by returning NotFound status for cases that the prefix does not exist. SeekForPrev in BlockBasedTable accordingly SeekToFirst instead of SeekToLast on the index iterator.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6297
      
      Test Plan: SeekForPrev of non-exsiting prefix is added to block_test.cc, and a test case is added in db_test2, which fails without the fix.
      
      Differential Revision: D19404695
      
      fbshipit-source-id: cafbbf95f8f60ff9ede9ccc99d25bfa1cf6fcdc3
      d2b4d42d
  2. 15 1月, 2020 3 次提交
  3. 14 1月, 2020 1 次提交
    • S
      Bug when multiple files at one level contains the same smallest key (#6285) · 894c6d21
      sdong 提交于
      Summary:
      The fractional cascading index is not correctly generated when two files at the same level contains the same smallest or largest user key.
      The result would be that it would hit an assertion in debug mode and lower level files might be skipped.
      This might cause wrong results when the same user keys are of merge operands and Get() is called using the exact user key. In that case, the lower files would need to further checked.
      The fix is to fix the fractional cascading index.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6285
      
      Test Plan: Add a unit test which would cause the assertion which would be fixed.
      
      Differential Revision: D19358426
      
      fbshipit-source-id: 39b2b1558075fd95e99491d462a67f9f2298c48e
      894c6d21
  4. 11 1月, 2020 3 次提交
    • Q
      More const pointers in C API (#6283) · 6733be03
      Qinfan Wu 提交于
      Summary:
      This makes it easier to call the functions from Rust as otherwise they require mutable types.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6283
      
      Differential Revision: D19349991
      
      Pulled By: wqfish
      
      fbshipit-source-id: e8da7a75efe8cd97757baef8ca844a054f2519b4
      6733be03
    • S
      Consider all compaction input files to compute the oldest ancestor time (#6279) · cfa58561
      Sagar Vemuri 提交于
      Summary:
      Look at all compaction input files to compute the oldest ancestor time.
      
      In https://github.com/facebook/rocksdb/issues/5992 we changed how creation_time (aka oldest-ancestor-time) table property of compaction output files is computed from max(creation-time-of-all-compaction-inputs) to min(creation-time-of-all-inputs). This exposed a bug where, during compaction, the creation_time:s of only the L0 compaction inputs were being looked at, and all other input levels were being ignored. This PR fixes the issue.
      Some TTL compactions when using Level-Style compactions might not have run due to this bug.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6279
      
      Test Plan: Enhanced the unit tests to validate that the correct time is propagated to the compaction outputs.
      
      Differential Revision: D19337812
      
      Pulled By: sagar0
      
      fbshipit-source-id: edf8a72f11e405e93032ff5f45590816debe0bb4
      cfa58561
    • M
      unordered_write incompatible with max_successive_merges (#6284) · eff5e076
      Maysam Yabandeh 提交于
      Summary:
      unordered_write is incompatible with non-zero max_successive_merges. Although we check this at runtime, we currently don't prevent the user from setting this combination in options. This has led to stress tests to fail with this combination is tried in ::SetOptions.
      The patch fixes that and also reverts the changes performed by https://github.com/facebook/rocksdb/pull/6254, in which max_successive_merges was mistakenly declared incompatible with unordered_write.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6284
      
      Differential Revision: D19356115
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: f06dadec777622bd75f267361c022735cf8cecb6
      eff5e076
  5. 10 1月, 2020 2 次提交
  6. 09 1月, 2020 6 次提交
  7. 08 1月, 2020 7 次提交
    • A
      JMH microbenchmarks for RocksJava (#6241) · 6477075f
      Adam Retter 提交于
      Summary:
      This is the start of some JMH microbenchmarks for RocksJava.
      
      Such benchmarks can help us decide on performance improvements of the Java API.
      
      At the moment, I have only added benchmarks for various Comparator options, as that is one of the first areas where I want to improve performance. I plan to expand this to many more tests.
      
      Details of how to compile and run the benchmarks are in the `README.md`.
      
      A run of these on a XEON 3.5 GHz 4vCPU (QEMU Virtual CPU version 2.5+) / 8GB RAM KVM with Ubuntu 18.04, OpenJDK 1.8.0_232, and gcc 8.3.0 produced the following:
      
      ```
      # Run complete. Total time: 01:43:17
      
      REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
      why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
      experiments, perform baseline and negative tests that provide experimental control, make sure
      the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
      Do not assume the numbers tell you what you want them to tell.
      
      Benchmark                                         (comparatorName)   Mode  Cnt       Score       Error  Units
      ComparatorBenchmarks.put                           native_bytewise thrpt   25   122373.920 ±  2200.538  ops/s
      ComparatorBenchmarks.put              java_bytewise_adaptive_mutex thrpt   25    17388.201 ±  1444.006  ops/s
      ComparatorBenchmarks.put          java_bytewise_non-adaptive_mutex thrpt   25    16887.150 ±  1632.204  ops/s
      ComparatorBenchmarks.put       java_direct_bytewise_adaptive_mutex thrpt   25    15644.572 ±  1791.189  ops/s
      ComparatorBenchmarks.put   java_direct_bytewise_non-adaptive_mutex thrpt   25    14869.601 ±  2252.135  ops/s
      ComparatorBenchmarks.put                   native_reverse_bytewise thrpt   25   116528.735 ±  4168.797  ops/s
      ComparatorBenchmarks.put      java_reverse_bytewise_adaptive_mutex thrpt   25    10651.975 ±   545.998  ops/s
      ComparatorBenchmarks.put  java_reverse_bytewise_non-adaptive_mutex thrpt   25    10514.224 ±   930.069  ops/s
      ```
      
      Indicating a ~7x difference between comparators implemented natively (C++) and those implemented in Java. Let's see if we can't improve on that in the near future...
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6241
      
      Differential Revision: D19290410
      
      Pulled By: pdillinger
      
      fbshipit-source-id: 25d44bf3a31de265502ed0c5d8a28cf4c7cb9c0b
      6477075f
    • M
      Skip CancelAllBackgroundWork if DBImpl is already closed (#6268) · 5709e97a
      Maysam Yabandeh 提交于
      Summary:
      WritePreparedTxnDB calls CancelAllBackgroundWork in its destructor to avoid dangling references to it from background job's SnapshotChecker callback. However, if the DBImpl is already closed, the info log might be closed with it, which causes memory leak when CancelAllBackgroundWork tries to print to the info log. The patch fixes that by calling CancelAllBackgroundWork only if the db is not closed already.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6268
      
      Differential Revision: D19303439
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: 4228a6be7e78d43c90630347baa89b008200bd15
      5709e97a
    • W
      parallel occ (#6240) · 1ab1231a
      wolfkdy 提交于
      Summary:
      This is a continuation of https://github.com/facebook/rocksdb/pull/5320/files
      I open a new mr for these purposes, half a year has past since the old mr is posted so it's almost impossible to fulfill some points below on the old mr, especially 5)
      1) add validation modes for optimistic txns
      2) modify unittests to test both modes
      3) make format
      4) refine hash functor
      5) push to master
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6240
      
      Differential Revision: D19301296
      
      fbshipit-source-id: 5b5b3cbd39558f43947f7d2dec6cd31a06386edb
      1ab1231a
    • H
      Implement getfreespace for WinEnv (#6265) · 2fdd8087
      Huisheng Liu 提交于
      Summary:
      A new interface method Env::GetFreeSpace was added in https://github.com/facebook/rocksdb/issues/4164. It needs to be implemented for Windows port. Some error_handler_test cases fail on Windows because recovery cannot succeed without free space being reported.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6265
      
      Differential Revision: D19303065
      
      fbshipit-source-id: 1f1a83e53f334284781cf61feabc996e87b945ca
      2fdd8087
    • Y
      Fix test in LITE mode (#6267) · a8b1085a
      Yanqin Jin 提交于
      Summary:
      Currently, the recently-added test DBTest2.SwitchMemtableRaceWithNewManifest
      fails in LITE mode since SetOptions() returns "Not supported". I do not want to
      put `#ifndef ROCKSDB_LITE` because it reduces test coverage. Instead, just
      trigger compaction on a different column family. The bg compaction thread
      calling LogAndApply() may race with thread calling SwitchMemtable().
      
      Test Plan (dev server):
      make check
      OPT=-DROCKSDB_LITE make check
      
      or run DBTest2.SwitchMemtableRaceWithNewManifest 100 times.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6267
      
      Differential Revision: D19301309
      
      Pulled By: riversand963
      
      fbshipit-source-id: 88cedcca2f985968ed3bb234d324ffa2aa04ca50
      a8b1085a
    • Y
      Fix error message (#6264) · bce5189f
      Yanqin Jin 提交于
      Summary:
      Fix an error message when CURRENT is not found.
      
      Test plan (dev server)
      ```
      make check
      ```
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6264
      
      Differential Revision: D19300699
      
      Pulled By: riversand963
      
      fbshipit-source-id: 303fa206386a125960ecca1dbdeff07422690caf
      bce5189f
    • C
      Add oldest snapshot sequence property (#6228) · 3e26a94b
      Connor1996 提交于
      Summary:
      Add oldest snapshot sequence property, so we can use `db.GetProperty("rocksdb.oldest-snapshot-sequence")` to get the sequence number of the oldest snapshot.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6228
      
      Differential Revision: D19264145
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: 67fbe5304d89cbc475bd404e30d1299f7b11c010
      3e26a94b
  8. 07 1月, 2020 4 次提交
    • Y
      Fix a data race for cfd->log_number_ (#6249) · 1aaa1458
      Yanqin Jin 提交于
      Summary:
      A thread calling LogAndApply may release db mutex when calling
      WriteCurrentStateToManifest() which reads cfd->log_number_. Another thread can
      call SwitchMemtable() and writes to cfd->log_number_.
      Solution is to cache the cfd->log_number_ before releasing mutex in
      LogAndApply.
      
      Test Plan (on devserver):
      ```
      $COMPILE_WITH_TSAN=1 make db_stress
      $./db_stress --acquire_snapshot_one_in=10000 --avoid_unnecessary_blocking_io=1 --block_size=16384 --bloom_bits=16 --bottommost_compression_type=zstd --cache_index_and_filter_blocks=1 --cache_size=1048576 --checkpoint_one_in=1000000 --checksum_type=kxxHash --clear_column_family_one_in=0 --compact_files_one_in=1000000 --compact_range_one_in=1000000 --compaction_ttl=0 --compression_max_dict_bytes=16384 --compression_type=zstd --compression_zstd_max_train_bytes=0 --continuous_verification_interval=0 --db=/dev/shm/rocksdb/rocksdb_crashtest_blackbox --db_write_buffer_size=1048576 --delpercent=5 --delrangepercent=0 --destroy_db_initially=0 --enable_pipelined_write=0  --flush_one_in=1000000 --format_version=5 --get_live_files_and_wal_files_one_in=1000000 --index_block_restart_interval=5 --index_type=0 --log2_keys_per_lock=22 --long_running_snapshots=0 --max_background_compactions=20 --max_bytes_for_level_base=10485760 --max_key=1000000 --max_manifest_file_size=16384 --max_write_batch_group_size_bytes=16 --max_write_buffer_number=3 --memtablerep=skip_list --mmap_read=0 --nooverwritepercent=1 --open_files=500000 --ops_per_thread=100000000 --partition_filters=0 --pause_background_one_in=1000000 --periodic_compaction_seconds=0 --prefixpercent=5 --progress_reports=0 --readpercent=45 --recycle_log_file_num=0 --reopen=20 --set_options_one_in=10000 --snapshot_hold_ops=100000 --subcompactions=2 --sync=1 --target_file_size_base=2097152 --target_file_size_multiplier=2 --test_batches_snapshots=1 --use_direct_io_for_flush_and_compaction=0 --use_direct_reads=0 --use_full_merge_v1=0 --use_merge=0 --use_multiget=1 --verify_checksum=1 --verify_checksum_one_in=1000000 --verify_db_one_in=100000 --write_buffer_size=4194304 --write_dbid_to_manifest=1 --writepercent=35
      ```
      Then repeat the following multiple times, e.g. 100 after compiling with tsan.
      ```
      $./db_test2 --gtest_filter=DBTest2.SwitchMemtableRaceWithNewManifest
      ```
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6249
      
      Differential Revision: D19235077
      
      Pulled By: riversand963
      
      fbshipit-source-id: 79467b52f48739ce7c27e440caa2447a40653173
      1aaa1458
    • Y
      Improve error msg for SstFileWriter Merge (#6261) · 946c43a0
      Yanqin Jin 提交于
      Summary:
      Reword the error message when keys are not added in strict ascending order.
      Specifically, original error message is not clear when application tries to
      call SstFileWriter::Merge() with duplicate keys.
      
      Test plan (dev server)
      ```
      make check
      ```
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6261
      
      Differential Revision: D19290398
      
      Pulled By: riversand963
      
      fbshipit-source-id: 4dc30a701414e6894db2eb024e3734470c22b371
      946c43a0
    • Q
      Add range delete function to C-API (#6259) · edaaa1ff
      Qinfan Wu 提交于
      Summary:
      It seems that the C-API doesn't expose the range delete functionality at the moment, so add the API.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6259
      
      Differential Revision: D19290320
      
      Pulled By: pdillinger
      
      fbshipit-source-id: 3f403a4c3446d2042d55f1ece7cdc9c040f40c27
      edaaa1ff
    • M
      Increase max_log_size in FlushJob to 1024 bytes (#6258) · 28e5a9a9
      Maysam Yabandeh 提交于
      Summary:
      When measure_io_stats_ is enabled, the volume of logging is beyond the default limit of 512 size. The patch allows the EventLoggerStream to change the limit, and also sets it to 1024 for FlushJob.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6258
      
      Differential Revision: D19279269
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: 3fb5d468dad488f289ac99d713378177eb7504d6
      28e5a9a9
  9. 04 1月, 2020 1 次提交
  10. 03 1月, 2020 2 次提交
    • M
      Print before AddErrors in stress tests (#6256) · 7c98d715
      Maysam Yabandeh 提交于
      Summary:
      Stress tests count number of errors and report them at the end. Not all the cases are accompanied with a log line which makes debugging difficult. The patch adds a log line to the remaining cases.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6256
      
      Differential Revision: D19268785
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: bdabcaa5c5c7edcb4ce4f25e38fd8a3fd9c7700b
      7c98d715
    • M
      Prevent an incompatible combination of options (#6254) · 48a678b7
      Maysam Yabandeh 提交于
      Summary:
      allow_concurrent_memtable_write is incompatible with non-zero max_successive_merges. Although we check this at runtime, we currently don't prevent the user from setting this combination in options. This has led to stress tests to fail with this combination is tried in ::SetOptions. The patch fixes that.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6254
      
      Differential Revision: D19265819
      
      Pulled By: maysamyabandeh
      
      fbshipit-source-id: 47f2e2dc26fe0972c7152f4da15dadb9703f1179
      48a678b7
  11. 31 12月, 2019 1 次提交
  12. 27 12月, 2019 1 次提交
  13. 25 12月, 2019 1 次提交
    • P
      Fix a clang analyzer report, and 'analyze' make rule (#6244) · 95d226d8
      Peter Dillinger 提交于
      Summary:
      Clang analyzer was falsely reporting on use of txn=nullptr.
      Added a new const variable so that it can properly prune impossible
      control flows.
      
      Also, 'make analyze' previously required setting USE_CLANG=1 as an
      environment variable, not a make variable, or else compilation errors
      like
      
      g++: error: unrecognized command line option ‘-Wshorten-64-to-32’
      
      Now USE_CLANG is not required for 'make analyze' (it's implied) and you
      can do an incremental analysis (recompile what has changed) with
      'USE_CLANG=1 make analyze_incremental'
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6244
      
      Test Plan: 'make -j24 analyze', 'make crash_test'
      
      Differential Revision: D19225950
      
      Pulled By: pdillinger
      
      fbshipit-source-id: 14f4039aa552228826a2de62b2671450e0fed3cb
      95d226d8
  14. 24 12月, 2019 1 次提交
  15. 22 12月, 2019 2 次提交
  16. 21 12月, 2019 3 次提交
    • A
      Add Transaction::MultiGet to db_stress (#6227) · d4da4128
      anand76 提交于
      Summary:
      Call Transaction::MultiGet from TestMultiGet() in db_stress. We add some Puts/Merges/Deletes into the transaction in order to exercise MultiGetFromBatchAndDB. There is no data verification on read, just check status. There is currently no read data verification in db_stress as it requires synchronization with writes. It needs to be tackled separately.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6227
      
      Test Plan: make crash_test_with_txn
      
      Differential Revision: D19204611
      
      Pulled By: anand1976
      
      fbshipit-source-id: 770d0e30d002e88626c264c58103f1d709bb060c
      d4da4128
    • S
      db_stress should not keep manifest files under checkpoint directory (#6233) · e0f9d11a
      sdong 提交于
      Summary:
      Recently db_stress starts to use a special Env that keeps all manifest files. This should not apply to checkpoint directory and causes test failure like this:
      
      Verification failed: Checkpoint gave inconsistent state. Status is IO error: While mkdir: /dev/shm/rocksdb/rocksdb_crashtest_whitebox/.checkpoint27.tmp: File exists
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6233
      
      Test Plan: Run crash_test with high chance of checkpoint and make sure it doesn't reproduce.
      
      Differential Revision: D19207250
      
      fbshipit-source-id: 12a931379e2e0572bb84aa658b6d03770c8551d4
      e0f9d11a
    • S
      db_stress: listners to implement all functions (#6197) · 9d36c066
      sdong 提交于
      Summary:
      Listners are one source of bugs because we frequently release some mutex to invoke them, which introduce race conditions. Implement all callback functions in db_stress's listener class, and randomly sleep.
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/6197
      
      Test Plan: Run crash_test for a while and see no obvious problem.
      
      Differential Revision: D19134015
      
      fbshipit-source-id: b9ea8be9366e4501759119520cd4f204943538f6
      9d36c066