Django Database Cache - Untouched expired entries are never culled unless MAX_ENTRIES is reached

The documentation for the Django database backend says:

Unlike other cache backends, the database cache does not support 
automatic culling of expired entries at the database level.
 Instead, expired cache entries are culled each time 
add(), set(), or touch() is called.

But this doesn’t seem to be what is happening:

In fact, expired entries are only deleted if MAX_ENTRIES is reached: https://github.com/django/django/blob/main/django/core/cache/backends/db.py#L130

But this then also triggers culling of non-expired entries if their number exceeds MAX_ENTRIES.

This is a problem if I want to drive a strategy where I only expire entries by time and never randomly cull them. In order to prevent random culling, I need to set MAX_ENTRIES to a very high unreachable number. But then, expired entries will never be deleted!

Am I maybe missing something? Or is the documentation incomplete here?
Is it a possible consideration to update the database caching backend to cull expired entries also when MAX_ENTRIES isn’t reached yet?

PS: The documentation also doesn’t mention that expired entries are removed if you try to get them: https://github.com/django/django/blob/main/django/core/cache/backends/db.py#L97

Hello, any news regarding this ? What did you do eventually ?

Thanks for this, I opened a ticket for the first infelicity in the documentation re: the interaction with MAX_ENTRIES.

In order to prevent random culling, I need to set MAX_ENTRIES to a very high unreachable number. But then, expired entries will never be deleted!

You should be able to set CULL_FREQUENCY to a very high, unreachable number, and set MAX_ENTRIES to 0.

We should probably optimize this use case to remove the unnecessary SELECT that would occur in this scenario (if cull_num in the implementation is 0, we already know we can exit without doing a SELECT that we’d otherwise need for a SELECT/DELETE pair).

I opened a ticket for that, too.