BugZero found this defect 247 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
3/12/2024
MongoDB Server
No affected releases provided.
No fixed releases provided.
After fixing SERVER-81007, this test began consistently failing. It's unclear what change led to the failures, but it seems the conversion to modules is not likely the culprit. Here is a successful test run from June 15th before the bug was introduced in SERVER-81007. Maybe there was some change in storex or WiredTiger code after the bug was introduced which leads to this consistent failure.
JIRAUSER1258229 commented on Mon, 27 Nov 2023 21:21:28 +0000: I take back what I said in my previous comment. When compaction is blocked by checkpoint, compaction is retried internally. However, EBUSY can still be returned for other reasons. If EBUSY is actually because of cache eviction pressure, WiredTiger would print it out. JIRAUSER1258229 commented on Tue, 19 Sep 2023 01:00:18 +0000: The error message is Compaction interrupted on table:collection-1906--5767142732412023233 due to cache eviction pressure which comes from the storage layer: Status WiredTigerIndexUtil::compact(OperationContext* opCtx, const std::string& uri) { ... if (ret == EBUSY) { return Status(ErrorCodes::Interrupted, str::stream() << "Compaction interrupted on " << uri.c_str() << " due to cache eviction pressure"); } Or Status WiredTigerRecordStore::doCompact(OperationContext* opCtx) { ... if (ret == EBUSY) { return Status(ErrorCodes::Interrupted, str::stream() << "Compaction interrupted on " << getURI().c_str() << " due to cache eviction pressure"); } This surprises me, EBUSY does not necessarily mean the cache is full. For example, compaction performs checkpoints that can return EBUSY for various reasons.