Andres Freund <andres@anarazel.de> writes:
> In essence, debug_invalidate_system_caches_always=1 in some important aspects
> behaves like debug_invalidate_system_caches_always=3, due to the syscache
> involvement.
Yeah. I think it's important to test those recursive invalidation
scenarios, but it could likely be done more selectively.
> What about having a mode where each "nesting" level of SearchCatCacheMiss
> allows only one interior InvalidateSystemCaches()?
An idea I'd been toying with was to make invals probabilistic, that is
there would be X% chance of an inval being forced at any particular
opportunity. Then you could dial X up or down to make a tradeoff
between speed and the extent of coverage you get from a single run.
(Over time, you could expect pretty complete coverage even with X
not very close to 1, I think.)
This could be extended to what you're thinking about by reducing X
(according to some rule or other) for each level of cache-flush
recursion. The argument to justify that is that recursive cache
flushes are VERY repetitive, so that even a small probability will
add up to full coverage of those code paths fairly quickly.
I've not worked out the math to justify any specific proposal
along this line, though.
regards, tom lane
