Andres Freund <and...@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