From ee33b95d9c2ecec170bc517783d7268a4bd0c793 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Tue, 9 Sep 2008 18:58:09 +0000
Subject: Improve the plan cache invalidation mechanism to make it invalidate
 plans when user-defined functions used in a plan are modified.  Also
 invalidate plans when schemas, operators, or operator classes are modified;
 but for these cases we just invalidate everything rather than tracking exact
 dependencies, since these types of objects seldom change in a production
 database.

Tom Lane; loosely based on a patch by Martin Pihlak.
---
 src/backend/utils/cache/ts_cache.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

(limited to 'src/backend/utils/cache/ts_cache.c')

diff --git a/src/backend/utils/cache/ts_cache.c b/src/backend/utils/cache/ts_cache.c
index 81ff577125e..33b415ac6f0 100644
--- a/src/backend/utils/cache/ts_cache.c
+++ b/src/backend/utils/cache/ts_cache.c
@@ -20,7 +20,7 @@
  * Copyright (c) 2006-2008, PostgreSQL Global Development Group
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/cache/ts_cache.c,v 1.7 2008/04/12 23:14:21 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/cache/ts_cache.c,v 1.8 2008/09/09 18:58:08 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -79,18 +79,19 @@ static Oid	TSCurrentConfigCache = InvalidOid;
 
 
 /*
- * We use this catcache callback to detect when a visible change to a TS
+ * We use this syscache callback to detect when a visible change to a TS
  * catalog entry has been made, by either our own backend or another one.
- * We don't get enough information to know *which* specific catalog row
- * changed, so we have to invalidate all related cache entries.  Fortunately,
- * it seems unlikely that TS configuration changes will occur often enough
- * for this to be a performance problem.
+ *
+ * In principle we could just flush the specific cache entry that changed,
+ * but given that TS configuration changes are probably infrequent, it
+ * doesn't seem worth the trouble to determine that; we just flush all the
+ * entries of the related hash table.
  *
  * We can use the same function for all TS caches by passing the hash
  * table address as the "arg".
  */
 static void
-InvalidateTSCacheCallBack(Datum arg, Oid relid)
+InvalidateTSCacheCallBack(Datum arg, int cacheid, ItemPointer tuplePtr)
 {
 	HTAB	   *hash = (HTAB *) DatumGetPointer(arg);
 	HASH_SEQ_STATUS status;
-- 
cgit v1.2.3