Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Well, we seem to be proof against cache-inval problems now
Date: 2001-01-05 06:18:47
Message-ID: 636.978675527@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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
  }
  
  /*

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2001-01-05 06:49:36
Subject: Re: time + date_part oddness?
Previous:From: The Hermit HackerDate: 2001-01-05 04:30:16
Subject: Re: running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group