Deflake unit test DBCompactionTest.CompactionLimiter

[cbi42]

The test has been flaky for a long time. It may be because threadpool's queue_len_ is accessed with relaxed memory order.

Test plan: I could not repro the failure locally: gtest-parallel --repeat=8000 --workers=100 ./db_compaction_test --gtest_filter="*CompactionLimiter*"

[facebook-github-bot]

@cbi42 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[ajkr]

I don't know how TEST_WaitForFlushMemTable() returns before compaction is scheduled. It looks like InstallSuperVersionAndScheduleWork() does both its things in one lock hold. Do you know how it happens?

[cbi42]

I don't know how TEST_WaitForFlushMemTable() returns before compaction is scheduled. It looks like InstallSuperVersionAndScheduleWork() does both its things in one lock hold. Do you know how it happens?

I was looking at the call to MaybeScheduleFlushOrCompaction() in BackgroundCallFlush() here. But I missed that InstallSuperVersionAndScheduleWork() is called right after flush result is installed here. You are right it looks like compaction should have been scheduled in InstallSuperVersionAndScheduleWork(). I'll look more into this.

[cbi42]

Updated PR summary, it may be due to threadpool's queue_len_ is accessed with relaxed memory order.

[facebook-github-bot]

@cbi42 merged this pull request in e2ef349.