-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Cache and Eviction
-
None
-
Storage Engines - Transactions
-
155.105
-
SE Transactions - 2026-08-28
-
5
Problem
While a disaggregated follower's ingest btree has a frozen prune_timestamp, every modified leaf in that tree is rejected by __evict_review with EBUSY. The eviction walk cannot tell: the walk-side copy of that check is bypassed under aggressive eviction, so it queues those pages anyway.
A walk pass ends as soon as the queue's 100 slots are filled and the next pass resumes from the saved tree, and a page that fails eviction is immediately re-queueable. Filling its full target also resets the tree's walk period to 0, so it is scored as the best tree in cache.
The result is a lock-in: the server queues 100 unevictable pages per pass indefinitely, never reaches another dhandle, and eviction stops entirely even though plenty of evictable content is resident. The size of the tree does not matter — it only has to supply 100 pages per pass.
Diagnostic builds panic with "Cache stuck for too long". Release builds hang instead: threads pulled into eviction assist cannot leave until cache usage falls below the trigger, which never happens.
Proposed solution
- Do not nominate pages eviction is guaranteed to reject — mirror _evict_review's prune-timestamp and precise-checkpoint gates in _evict_try_queue_page, unconditional on aggressive mode.
- Skip a garbage-collect tree whose prune timestamp has not advanced since a visit that produced no evictions, so the pathological case costs one comparison instead of a full tree walk.
- Key tree productivity on eviction outcome rather than pages queued, so a tree whose queued pages all failed backs off like one that queued nothing.
Definition of done
- Eviction continues to make progress while an ingest btree's prune timestamp is frozen, and the walk rotates through the dhandle list instead of resuming on the same tree every pass.
- A test covers the case: a frozen prune timestamp plus evictable content in other trees must not stall eviction.
- Stress runs of the disagg switch stepdown-async tasks no longer reproduce such cache-stuck failure, the cache may still stuck when ingest table dominates the cache but it shouldn't stuck when there're evictable pages.