-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines - Transactions
-
75.378
-
None
-
None
Context
Step-up drains the ingest table into the stable table, then clears it with a whole-table
non-transactional truncate (__layered_clear_ingest_table). WT-17989 set
WT_SESSION_IGNORE_CACHE_SIZE across that clear for standalone builds only; WT-18253 made it
unconditional, since the cache stuck it works around is not standalone-specific.
Why it is temporary
Dirty ingest pages are only reclaimable below the table's prune timestamp, which is reset once the
whole table has drained, so the drain fills the cache and withholds the memory that would relieve
it. Exempting the drain session breaks that cycle but leaves the overshoot unbounded.
Definition of done
- The drain releases memory as it goes (WT-18058) or throttles itself under cache pressure.
- The flag, its save/restore, and the FIXME naming this ticket are gone from
__layered_clear_ingest_table. - A small-cache test that fills the ingest table past the dirty capacity asserts step-up completes
within a bound, with cache bytes staying under the eviction trigger.
- is related to
-
WT-17989 test/format (mode=switch) [Elegant stepdown bugs] WT_ROLLBACK draining ingest table during step-up causes step-up failure
-
- Closed
-
-
WT-18253 Cache stuck in disagg switch mode cache full: no
-
- Closed
-
-
WT-18058 Replace ingest-table whole-table clear with incremental per-page drain
-
- Open
-