Enforces a row cap on cache_data, then clears anything genuinely expired.
The row cap is the only thing that works here, and it is measured: all 144
cache_data rows on the reference site have expire = -1, so an expire-based
sweep removes exactly zero of them. 70 are RouteProvider's per-URL route cache
-- cid route:[language]=en:[query_parameters]=<qs>:<path>, written at
RouteProvider.php:222 with CACHE_PERMANENT -- so every distinct URL a scanner
probes adds a permanent row. (The mechanism is RouteProvider, not PageCache;
both write into the data bin but only the route cache is keyed per URL.)
The cap is Drupal's own: cache.data reports getMaxRows() === 5000, set by
DatabaseBackend::DEFAULT_MAX_ROWS, enforced by DatabaseBackend
::garbageCollection() -- which only ever runs from SystemHooks::cron(), the one
hook this runtime cannot call. So the policy was always there and the caller
never was.
Ordering by created, cid rather than core's created <= pivot:
created is a float with millisecond resolution and a single request writes
several rows, so ties are ordinary and core's condition over-deletes them.
Enforces a row cap on cache_data, then clears anything genuinely expired.
The row cap is the only thing that works here, and it is measured: all 144 cache_data rows on the reference site have
expire = -1, so an expire-based sweep removes exactly zero of them. 70 are RouteProvider's per-URL route cache -- cidroute:[language]=en:[query_parameters]=<qs>:<path>, written at RouteProvider.php:222 with CACHE_PERMANENT -- so every distinct URL a scanner probes adds a permanent row. (The mechanism is RouteProvider, not PageCache; both write into thedatabin but only the route cache is keyed per URL.)The cap is Drupal's own: cache.data reports getMaxRows() === 5000, set by DatabaseBackend::DEFAULT_MAX_ROWS, enforced by DatabaseBackend ::garbageCollection() -- which only ever runs from SystemHooks::cron(), the one hook this runtime cannot call. So the policy was always there and the caller never was.
Ordering by
created, cidrather than core'screated <= pivot:createdis a float with millisecond resolution and a single request writes several rows, so ties are ordinary and core's condition over-deletes them.