mirror of
https://github.com/timescale/timescaledb.git
synced 2025-05-16 18:43:18 +08:00
TimescaleDB cache invalidation happens as a side effect of doing a full SQL statement (INSERT/UPDATE/DELETE) on a catalog table (via table triggers). However, triggers aren't invoked when using PostgreSQL's internal catalog API for updates, since PostgreSQL's catalog tables don't have triggers that require full statement parsing, planning, and execution. Since we are now using the regular PostgreSQL catalog update API for some TimescaleDB catalog operations, we need to do cache invalidation also on such operations. This change adds cache invalidation when updating catalogs using the internal (C) API and also makes the cache invalidation more fine grained. For instance, caches are no longer invalidated on some INSERTS that do not affect the validity of objects already in the cache, such as adding a new chunk.
9 lines
501 B
SQL
9 lines
501 B
SQL
-- this trigger function causes an invalidation event on the table whose name is
|
|
-- passed in as the first element.
|
|
CREATE OR REPLACE FUNCTION _timescaledb_cache.invalidate_relcache_trigger()
|
|
RETURNS TRIGGER AS '$libdir/timescaledb', 'invalidate_relcache_trigger' LANGUAGE C STRICT;
|
|
|
|
-- This function is only used for debugging
|
|
CREATE OR REPLACE FUNCTION _timescaledb_cache.invalidate_relcache(catalog_table REGCLASS)
|
|
RETURNS BOOLEAN AS '$libdir/timescaledb', 'invalidate_relcache' LANGUAGE C STRICT;
|