In PrepareToInvalidateCacheTuple, don't force initialization of catalog

caches that we don't actually need to touch.  This saves some trivial
number of cycles and avoids certain cases of deadlock when doing concurrent
VACUUM FULL on system catalogs.  Per report from Gavin Roy.

Backpatch to 8.2.  In earlier versions, CatalogCacheInitializeCache didn't
lock the relation so there's no deadlock risk (though that certainly had
plenty of risks of its own).

diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c
index f36384510c99bca99ac9e5835c4119510a007339..99004cfab62b47c2ae06253678431c2b0159dbd3 100644 (file)
--- a/src/backend/utils/cache/catcache.c
+++ b/src/backend/utils/cache/catcache.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/utils/cache/catcache.c,v 1.140 2008/01/01 19:45:53 momjian Exp $
+ *       $PostgreSQL: pgsql/src/backend/utils/cache/catcache.c,v 1.141 2008/03/05 17:01:26 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1781,13 +1781,13 @@ PrepareToInvalidateCacheTuple(Relation relation,
 
        for (ccp = CacheHdr->ch_caches; ccp; ccp = ccp->cc_next)
        {
+               if (ccp->cc_reloid != reloid)
+                       continue;
+
                /* Just in case cache hasn't finished initialization yet... */
                if (ccp->cc_tupdesc == NULL)
                        CatalogCacheInitializeCache(ccp);
 
-               if (ccp->cc_reloid != reloid)
-                       continue;
-
                (*function) (ccp->id,
                                         CatalogCacheComputeTupleHashValue(ccp, tuple),
                                         &tuple->t_self,