The code treats read_gen_oldest as though it is an older value than the current read generation. In fact, read_gen_oldest can sometimes be far in the future relative to the current read generation.

It is not clear how often this happens, or whether it causes any problems. But is merits some investigation. At a minimum, we should change the comments to reflect reality. But it would probably be better to cap the value of read_gen_oldest to be the current read generation.

read_gen_oldest is described in evict.h as, "Oldest read generation the eviction server saw in its last queue load." This is almost true. It is actually the oldest eviction score the eviction server saw in its last queue load. When loading pages into an eviction queue, the eviction server computes a score for each page based on the page's read generation. This score is usually just the page's read generation. But for pages the cache wants to prioritize, it returns the read generation plus a constant – 10,000 for metadata pages, 1,000 for internal pages.

So if the eviction server queues a set of pages that all have eviction scores with these offsets, it can wind up setting read_gen_oldest to a value that is in the future relative to the current read generation.

read_gen_oldest is only used one place, in __wti_evict_read_gen_new(), which sets the read generation for a newly loaded page to halfway between the current and oldest read generations. The idea is that by giving a page an older read generation the first time it is accessed, WT protects the cache from large scans that touch a lot of pages just once.

Intuitively, it seems that this should be a rare occurrence. We are unlikely to queue an entire batch of pages that have these offsets added into their eviction scores. But in FTDC from a 100% update YCSB load (see comment below) I saw this happening regularly, with the oldest read generation moving further and further from the current read generation.