Skip to content

Commit 9a75803

Browse files
tglsfdctglsfdc
committed
Remove CatalogCacheFlushRelation, and the reloidattr infrastructure that was
needed by nothing else. The restructuring I just finished doing on cache management exposed to me how silly this routine was. Its function was to go into the catcache and blow away all entries related to a given relation when there was a relcache flush on that relation. However, there is no point in removing a catcache entry if the catalog row it represents is still valid --- and if it isn't valid, there must have been a catcache entry flush on it, because that's triggered directly by heap_update or heap_delete on the catalog row. So this routine accomplished nothing except to blow away valid cache entries that we'd very likely be wanting in the near future to help reconstruct the relcache entry. Dumb. On top of which, it required a subtle and easy-to-get-wrong attribute in syscache definitions, ie, the column containing the OID of the related relation if any. Removing that is a very useful maintenance simplification.
1 parent 68446b2 commit 9a75803

File tree

4 files changed

+6
-167
lines changed

4 files changed

+6
-167
lines changed

‎src/backend/utils/cache/catcache.c

Lines changed: 1 addition & 88 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/utils/cache/catcache.c,v 1.149 2010/02/07 20:48:10 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/utils/cache/catcache.c,v 1.150 2010/02/08 05:53:55 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -672,91 +672,6 @@ ResetCatalogCaches(void)
672672
CACHE1_elog(DEBUG2, "end of ResetCatalogCaches call");
673673
}
674674

675-
/*
676-
* CatalogCacheFlushRelation
677-
*
678-
* This is called by RelationFlushRelation() to clear out cached information
679-
* about a relation being dropped. (This could be a DROP TABLE command,
680-
* or a temp table being dropped at end of transaction, or a table created
681-
* during the current transaction that is being dropped because of abort.)
682-
* Remove all cache entries relevant to the specified relation OID.
683-
*/
684-
void
685-
CatalogCacheFlushRelation(Oid relId)
686-
{
687-
CatCache *cache;
688-
689-
CACHE2_elog(DEBUG2, "CatalogCacheFlushRelation called for %u", relId);
690-
691-
for (cache = CacheHdr->ch_caches; cache; cache = cache->cc_next)
692-
{
693-
int i;
694-
695-
/* We can ignore uninitialized caches, since they must be empty */
696-
if (cache->cc_tupdesc == NULL)
697-
continue;
698-
699-
/* Does this cache store tuples associated with relations at all? */
700-
if (cache->cc_reloidattr == 0)
701-
continue; /* nope, leave it alone */
702-
703-
/* Yes, scan the tuples and remove those related to relId */
704-
for (i = 0; i < cache->cc_nbuckets; i++)
705-
{
706-
Dlelem *elt,
707-
*nextelt;
708-
709-
for (elt = DLGetHead(&cache->cc_bucket[i]); elt; elt = nextelt)
710-
{
711-
CatCTup *ct = (CatCTup *) DLE_VAL(elt);
712-
Oid tupRelid;
713-
714-
nextelt = DLGetSucc(elt);
715-
716-
/*
717-
* Negative entries are never considered related to a rel,
718-
* even if the rel is part of their lookup key.
719-
*/
720-
if (ct->negative)
721-
continue;
722-
723-
if (cache->cc_reloidattr == ObjectIdAttributeNumber)
724-
tupRelid = HeapTupleGetOid(&ct->tuple);
725-
else
726-
{
727-
bool isNull;
728-
729-
tupRelid =
730-
DatumGetObjectId(fastgetattr(&ct->tuple,
731-
cache->cc_reloidattr,
732-
cache->cc_tupdesc,
733-
&isNull));
734-
Assert(!isNull);
735-
}
736-
737-
if (tupRelid == relId)
738-
{
739-
if (ct->refcount > 0 ||
740-
(ct->c_list && ct->c_list->refcount > 0))
741-
{
742-
ct->dead = true;
743-
/* parent list must be considered dead too */
744-
if (ct->c_list)
745-
ct->c_list->dead = true;
746-
}
747-
else
748-
CatCacheRemoveCTup(cache, ct);
749-
#ifdef CATCACHE_STATS
750-
cache->cc_invals++;
751-
#endif
752-
}
753-
}
754-
}
755-
}
756-
757-
CACHE1_elog(DEBUG2, "end of CatalogCacheFlushRelation call");
758-
}
759-
760675
/*
761676
* CatalogCacheFlushCatalog
762677
*
@@ -820,7 +735,6 @@ CatCache *
820735
InitCatCache(int id,
821736
Oid reloid,
822737
Oid indexoid,
823-
int reloidattr,
824738
int nkeys,
825739
const int *key,
826740
int nbuckets)
@@ -884,7 +798,6 @@ InitCatCache(int id,
884798
cp->cc_indexoid = indexoid;
885799
cp->cc_relisshared = false; /* temporary */
886800
cp->cc_tupdesc = (TupleDesc) NULL;
887-
cp->cc_reloidattr = reloidattr;
888801
cp->cc_ntup = 0;
889802
cp->cc_nbuckets = nbuckets;
890803
cp->cc_nkeys = nkeys;

‎src/backend/utils/cache/relcache.c

Lines changed: 1 addition & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.303 2010/02/07 20:48:10 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.304 2010/02/08 05:53:55 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -1916,13 +1916,6 @@ RelationClearRelation(Relation relation, bool rebuild)
19161916
/* Mark it invalid until we've finished rebuild */
19171917
relation->rd_isvalid = false;
19181918

1919-
/*
1920-
* Clear out catcache's entries for this relation. This is a bit of
1921-
* a hack, but it's a convenient place to do it. (XXX do we really
1922-
* still need this?)
1923-
*/
1924-
CatalogCacheFlushRelation(RelationGetRelid(relation));
1925-
19261919
/*
19271920
* If we're really done with the relcache entry, blow it away. But if
19281921
* someone is still using it, reconstruct the whole deal without moving
@@ -2468,8 +2461,6 @@ RelationBuildLocalRelation(const char *relname,
24682461
*
24692462
* XXX this list had better match the relations specially handled in
24702463
* RelationCacheInitializePhase2/3.
2471-
*
2472-
* XXX do we need this at all??
24732464
*/
24742465
switch (relid)
24752466
{

0 commit comments

Comments
 (0)