mirror of https://github.com/facebook/rocksdb.git
b3c54186ab
Summary: In rare cases, optimistic transaction commit returns TryAgain. This change tolerates that intentional behavior in db_stress, up to a small limit in a row. This way, we don't miss a possible regression with excessive TryAgain, and trying again (rolling back the transaction) should have a well renewed chance of success as the writes will be associated with fresh sequence numbers. Also, some of the APIs were not clear about Transaction semantics, so I have clarified: * (Best I can tell....) Destroying a Transaction is safe without calling Rollback() (or at least should be). I don't know why it's a common pattern in our test code and examples to rollback before unconditional destruction. Stress test updated not to call Rollback unnecessarily (to test safe destruction). * Despite essentially doing what is asked, simply trying Commit() again when it returns TryAgain does not have a chance of success, because of the transaction being bound to the DB state at the time of operations before Commit. Similar logic applies to Busy AFAIK. Commit() API comments updated, and expanded unit test in optimistic_transaction_test. Also also, because I can't stop myself, I refactored a good portion of the transaction handling code in db_stress. * Avoid existing and new copy-paste for most transaction interactions with a new ExecuteTransaction (higher-order) function. * Use unique_ptr (nicely complements removing unnecessary Rollbacks) * Abstract out a pattern for safely calling std::terminate() and use it in more places. (The TryAgain errors we saw did not have stack traces because of "terminate called recursively".) Intended follow-up: resurrect use of `FLAGS_rollback_one_in` but also include non-trivial cases Pull Request resolved: https://github.com/facebook/rocksdb/pull/11653 Test Plan: this is the test :) Also, temporarily bypassed the new retry logic and boosted the chance of hitting TryAgain. Quickly reproduced the TryAgain error. Then re-enabled the new retry logic, and was not able to hit the error after running for tens of minutes, even with the boosted chances. Reviewed By: cbi42 Differential Revision: D47882995 Pulled By: pdillinger fbshipit-source-id: 21eadb1525423340dbf28d17cf166b9583311a0d |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| batched_ops_stress.cc | ||
| cf_consistency_stress.cc | ||
| db_stress.cc | ||
| db_stress_common.cc | ||
| db_stress_common.h | ||
| db_stress_compaction_filter.h | ||
| db_stress_driver.cc | ||
| db_stress_driver.h | ||
| db_stress_env_wrapper.h | ||
| db_stress_gflags.cc | ||
| db_stress_listener.cc | ||
| db_stress_listener.h | ||
| db_stress_shared_state.cc | ||
| db_stress_shared_state.h | ||
| db_stress_stat.cc | ||
| db_stress_stat.h | ||
| db_stress_table_properties_collector.h | ||
| db_stress_test_base.cc | ||
| db_stress_test_base.h | ||
| db_stress_tool.cc | ||
| expected_state.cc | ||
| expected_state.h | ||
| expected_value.cc | ||
| expected_value.h | ||
| multi_ops_txns_stress.cc | ||
| multi_ops_txns_stress.h | ||
| no_batched_ops_stress.cc | ||