Fix test breakage (#12915)

Summary:
https://github.com/facebook/rocksdb/issues/12891  updated this deletion rate in the test to be much higher, which makes the test flaky. The rate is being intentionally set to very low to maximize the retention of a ".log.trash" file after DB closes. This PR just change it back.

Pull Request resolved: https://github.com/facebook/rocksdb/pull/12915

Reviewed By: ltamasi

Differential Revision: D60776312

Pulled By: jowlyzhang

fbshipit-source-id: d193557a042c65816fcc337cceb09905e042e9f6
This commit is contained in:
Yu Zhang 2024-08-05 12:26:18 -07:00 committed by Facebook GitHub Bot
parent d12aaf23ca
commit 36b061a6c7
1 changed files with 4 additions and 3 deletions

View File

@ -917,11 +917,12 @@ TEST_P(DBWALTestWithParam, WALTrashCleanupOnOpen) {
// Create 4 files in L0 // Create 4 files in L0
for (char v = 'a'; v <= 'd'; v++) { for (char v = 'a'; v <= 'd'; v++) {
if (v == 'c') { if (v == 'c') {
// Maximize the change that the last log file will be preserved in trash // Maximize the chance that the last log file will be preserved in trash
// before restarting the DB. // before restarting the DB. (Enable slow deletion but at a very slow
// deletion rate)
// We have to set this on the 2nd to last file for it to delay deletion // We have to set this on the 2nd to last file for it to delay deletion
// on the last file. (Quirk of DeleteScheduler::BackgroundEmptyTrash()) // on the last file. (Quirk of DeleteScheduler::BackgroundEmptyTrash())
options.sst_file_manager->SetDeleteRateBytesPerSecond(1024 * 1024); options.sst_file_manager->SetDeleteRateBytesPerSecond(1);
} }
ASSERT_OK(Put("Key2", DummyString(1024, v))); ASSERT_OK(Put("Key2", DummyString(1024, v)));
ASSERT_OK(Put("Key3", DummyString(1024, v))); ASSERT_OK(Put("Key3", DummyString(1024, v)));