Summary

In __evict_skip_dirty_candidate, the check newest_commit_timestamp > prune_timestamp runs before the prune_timestamp != WT_TS_NONE guard. Because WT_TS_NONE == 0, every timestamped page on a garbage-collect btree is incorrectly skipped for eviction until prune_timestamp is explicitly set (i.e., until the first GC sweep completes). This causes cache to become stuck during that window.

Impact

Cache stuck, disaggregated storage only. Reproduces under test/format disagg-switch mode.

File

• src/evict/evict_lru.c

Fix

Wrap both inner checks inside a single if (prune_timestamp != WT_TS_NONE) guard:

// src/evict/evict_lru.c — __evict_skip_dirty_candidate
 if (F_ISSET(btree, WT_BTREE_GARBAGE_COLLECT)) {
     wt_timestamp_t prune_timestamp = ...;
-    if (newest_commit_timestamp > prune_timestamp) { ... return true; }
-    if (prune_timestamp != WT_TS_NONE &&
-      page->modify->rec_prune_timestamp >= prune_timestamp) { ... return true; }
+    if (prune_timestamp != WT_TS_NONE) {
+        if (newest_commit_timestamp > prune_timestamp) { ... return true; }
+        if (rec_prune_timestamp >= prune_timestamp) { ... return true; }
+    }
 }

Notes

Discovered during development on the WT-16973 clean-scrub eviction branch (PR #13605). Disagg only. Fix is independent of that feature and should be applied directly to develop.