Replace CLOBBER_CACHE_ALWAYS with run-time GUC

Forced cache invalidation (CLOBBER_CACHE_ALWAYS) has been impractical
to use for testing in PostgreSQL because it's so slow and because it's
toggled on/off only at build time.  It is helpful when hunting bugs in
any code that uses the sycache/relcache because causes cache
invalidations to be injected whenever it would be possible for an
invalidation to occur, whether or not one was really pending.

Address this by providing run-time control over cache clobber
behaviour using the new debug_invalidate_system_caches_always GUC.
Support is not compiled in at all unless assertions are enabled or
CLOBBER_CACHE_ENABLED is explicitly defined at compile time.  It
defaults to 0 if compiled in, so it has negligible effect on assert
build performance by default.

When support is compiled in, test code can now set
debug_invalidate_system_caches_always=1 locally to a backend to test
specific queries, functions, extensions, etc.  Or tests can toggle it
globally for a specific test case while retaining normal performance
during test setup and teardown.

For backwards compatibility with existing test harnesses and scripts,
debug_invalidate_system_caches_always defaults to 1 if
CLOBBER_CACHE_ALWAYS is defined, and to 3 if CLOBBER_CACHE_RECURSIVE
is defined.

CLOBBER_CACHE_ENABLED is now visible in pg_config_manual.h, as is the
related RECOVER_RELATION_BUILD_MEMORY setting for the relcache.

Author: Craig Ringer <craig.ringer@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/CAMsr+YF=+ctXBZj3ywmvKNUjWpxmuTuUKuv-rgbHGX5i5pLstQ@mail.gmail.com

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();