Well, we seem to be proof against cache-inval problems now

I just finished running the parallel regress tests with inval.c rigged
to flush the relcache and syscache at every available opportunity,
that is anytime we could recognize a shared-cache-inval message from
another backend (see diff below).  This setup gives a whole new universe
of meaning to the word "slow" --- it took *three full days* to run the
standard "make check" procedure, including eighteen hours just to do the
"vacuum template1" part of initdb.  I kid you not.  But it worked.
Looks like the unexpected-cache-entry-drop class of problems are indeed
gone.

BTW, the reason the diff is rigged not to allow recursive cache flush
is not that it wouldn't work, it's that I didn't expect to live long
enough to finish such a test.  I didn't originally have that restriction
in there (and indeed found a bug that way: relcache flush could go into
an infinite loop if hit with another SI inval before it'd finished the
initial flush).  After fixing that bug, initdb was making steady
progress, but not at a rate that I wanted to wait out...
        regards, tom lane

*** src/backend/utils/cache/inval.c.orig    Wed Nov 15 23:57:44 2000
--- src/backend/utils/cache/inval.c    Mon Jan  1 17:27:53 2001
***************
*** 643,649 ****
--- 643,661 ----     elog(DEBUG, "DiscardInvalid called"); #endif     /* defined(INVALIDDEBUG) */ 
+ #if 1
+     /* DEBUG CHECK ONLY ... force cache reset at any opportunity */
+     static bool inReset = false;
+ 
+     if (! IsBootstrapProcessingMode() && !inReset)
+     {
+         inReset = true;
+         ResetSystemCaches();
+         inReset  = false;
+     }
+ #else     InvalidateSharedInvalid(CacheIdInvalidate, ResetSystemCaches);
+ #endif }  /*