-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Not Applicable
-
None
-
Storage Engines, Storage Engines - Transactions
-
SE Transactions - 2025-07-18
-
5
It appears that in some cases WT_SESSION::drop can return EBUSY due to the WT_UNCOMMITTED_DATA sub-level error ("the table has uncommitted data and cannot be dropped yet") despite there being no uncommitted data on the table from the application's perspective. In some cases simply retrying the WT_SESSION::drop allows it to succeed, but in other cases retrying the WT_SESSION::drop continues to return EBUSY indefinitely.
- is depended on by
-
SERVER-107058 Remove ObjectIsBusy retry loop in StorageEngineImpl::dropSpillTable
-
- Open
-
- is duplicated by
-
WT-14853 WT_SESSION::drop after WT_SESSION::truncate can return EBUSY indefinitely
-
- Closed
-
- is related to
-
SERVER-106947 Infinite log messages after dropping database
-
- Open
-
-
SERVER-100890 Investigate uncommitted data during drop call
-
- Backlog
-
-
WT-14853 WT_SESSION::drop after WT_SESSION::truncate can return EBUSY indefinitely
-
- Closed
-
-
SERVER-106596 Truncate spill table before drop
-
- Blocked
-
-
SERVER-107034 Re-enable disabled query tests that spill in in-memory configurations
-
- Blocked
-
-
SERVER-107652 Ensure that spill table doesn't hold open storage snapshot across API calls
-
- In Code Review
-
-
SERVER-107033 Temporarily disable some query tests that spill in in-memory configurations
-
- Closed
-
-
WT-10576 Return EBUSY on forced drop if there is an active transaction
-
- Closed
-
- related to
-
SERVER-106835 Hanging drop-pending collections without holders in MongoDB 8.x
-
- Open
-
-
WT-14636 Investigate pending table drop
-
- Open
-
-
SERVER-103273 Drop SpillTable from spill engine on destruction
-
- Closed
-