Add some test scaffolding to allow cache-flush stress testing (and I do

mean stress ... system is orders of magnitude slower with this enabled).

1 files changed, 31 insertions, 1 deletions

diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 437bd4b0869..ba2be48d1a2 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -80,7 +80,7 @@
  * Portions Copyright (c) 1994, Regents of the University of California
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/cache/inval.c,v 1.74 2005/11/22 18:17:24 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/cache/inval.c,v 1.75 2006/01/19 21:49:21 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -625,6 +625,36 @@ AcceptInvalidationMessages(void)
 {
 	ReceiveSharedInvalidMessages(LocalExecuteInvalidationMessage,
 								 InvalidateSystemCaches);
+
+	/*
+	 * 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.
+	 *
+	 * 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.
+	 */
+#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)
+	InvalidateSystemCaches();
+#endif
 }
 
 /*