1 files changed, 24 insertions, 24 deletions

diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 0837054e7c6..f54dc12b718 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -109,6 +109,7 @@
 #include "storage/sinval.h"
 #include "storage/smgr.h"
 #include "utils/catcache.h"
+#include "utils/guc.h"
 #include "utils/inval.h"
 #include "utils/memdebug.h"
 #include "utils/memutils.h"
@@ -179,6 +180,8 @@ static SharedInvalidationMessage *SharedInvalidMessagesArray;
 static int	numSharedInvalidMessagesArray;
 static int	maxSharedInvalidMessagesArray;
 
+/* GUC storage */
+int debug_invalidate_system_caches_always = 0;
 
 /*
  * Dynamically-registered callback functions.  Current implementation
@@ -689,35 +692,32 @@ AcceptInvalidationMessages(void)
 	/*
 	 * Test code to force cache flushes anytime a flush could happen.
 	 *
-	 * If used with CLOBBER_FREED_MEMORY, CLOBBER_CACHE_ALWAYS provides a
-	 * fairly thorough test that the system contains no cache-flush hazards.
-	 * However, it also makes the system unbelievably slow --- the regression
-	 * tests take about 100 times longer than normal.
+	 * This helps detect intermittent faults caused by code that reads a
+	 * cache entry and then performs an action that could invalidate the entry,
+	 * but rarely actually does so.  This can spot issues that would otherwise
+	 * only arise with badly timed concurrent DDL, for example.
 	 *
-	 * If you're a glutton for punishment, try CLOBBER_CACHE_RECURSIVELY. This
-	 * slows things by at least a factor of 10000, so I wouldn't suggest
-	 * trying to run the entire regression tests that way.  It's useful to try
-	 * a few simple tests, to make sure that cache reload isn't subject to
-	 * internal cache-flush hazards, but after you've done a few thousand
-	 * recursive reloads it's unlikely you'll learn more.
+	 * The default debug_invalidate_system_caches_always = 0 does no forced cache flushes.
+	 *
+	 * If used with CLOBBER_FREED_MEMORY, debug_invalidate_system_caches_always = 1
+	 * (CLOBBER_CACHE_ALWAYS) provides a fairly thorough test that the system
+	 * contains no cache-flush hazards.  However, it also makes the system
+	 * unbelievably slow --- the regression tests take about 100 times longer
+	 * than normal.
+	 *
+	 * If you're a glutton for punishment, try debug_invalidate_system_caches_always = 3
+	 * (CLOBBER_CACHE_RECURSIVELY).  This slows things by at least a factor
+	 * of 10000, so I wouldn't suggest trying to run the entire regression
+	 * tests that way.  It's useful to try a few simple tests, to make sure
+	 * that cache reload isn't subject to internal cache-flush hazards, but
+	 * after you've done a few thousand recursive reloads it's unlikely
+	 * you'll learn more.
 	 */
-#if defined(CLOBBER_CACHE_ALWAYS)
-	{
-		static bool in_recursion = false;
-
-		if (!in_recursion)
-		{
-			in_recursion = true;
-			InvalidateSystemCaches();
-			in_recursion = false;
-		}
-	}
-#elif defined(CLOBBER_CACHE_RECURSIVELY)
+#ifdef CLOBBER_CACHE_ENABLED
 	{
 		static int	recursion_depth = 0;
 
-		/* Maximum depth is arbitrary depending on your threshold of pain */
-		if (recursion_depth < 3)
+		if (recursion_depth < debug_invalidate_system_caches_always)
 		{
 			recursion_depth++;
 			InvalidateSystemCaches();