summaryrefslogtreecommitdiff
path: root/src/backend/utils/cache/ts_cache.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-09-09 18:58:09 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-09-09 18:58:09 +0000
commitee33b95d9c2ecec170bc517783d7268a4bd0c793 (patch)
tree9012453a44799d20b15b2e4dcb1fb5e6784e2a7e /src/backend/utils/cache/ts_cache.c
parentc06629c72e7e3d435e207c2f80de3aa8a97c1d04 (diff)
downloadpostgresql-ee33b95d9c2ecec170bc517783d7268a4bd0c793.tar.gz
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.
Diffstat (limited to 'src/backend/utils/cache/ts_cache.c')
-rw-r--r--src/backend/utils/cache/ts_cache.c15
1 files changed, 8 insertions, 7 deletions
diff --git a/src/backend/utils/cache/ts_cache.c b/src/backend/utils/cache/ts_cache.c
index 81ff577125..33b415ac6f 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;