-
Type:
Improvement
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: 3.2.9, 3.3.12
-
Component/s: Storage
-
Labels:None
-
Backwards Compatibility:Fully Compatible
-
Backport Requested:v3.4, v3.2
-
Sprint:Storage 2017-03-27, Storage 2017-04-17, Storage 2017-05-08
-
Linked BF Score:5
There are multiple places in the code where there are problems related to handling WT_CACHE_FULL error returns. Three examples of code paths that need to be changed to handle WT_CACHE_FULL properly are:
- If an index build would use more space than is available in memory. The particular error is encountered while cleaning up after such a problem, the solution is to retry the cleanup until it succeeds.
- In WiredTigerSessionCache::releaseSession the call to haveDropsQueued results in a call to syncSizeInfo, which results in an update to the size storer table that can fail.
- When an index build fails due to cache full, the path to rolling back the index build involves first updating the MongoDB metadata table via KVCollectionCatalogEntry::removeIndex. Since the cache is full, doing the update into the metadata also fails with WT_CACHE_FULL.
- depends on
-
SERVER-28059 Enhance in-memory storage engine configuration
-
- Closed
-
-
WT-2932 Allow applications to selectively ignore cache limit with in-memory configuration
-
- Closed
-
- related to
-
SERVER-29005 Review cache full handling for in-memory workloads
-
- Open
-
-
SERVER-24935 Fassert due to WT_CACHE_FULL in failed index build cleanup on inMemory engine
-
- Closed
-
-
SERVER-27014 Disable inmem_full.js test until cache full handling is improved
-
- Closed
-