Syscache/relcache invalidation event callbacks
От | Tom Lane |
---|---|
Тема | Syscache/relcache invalidation event callbacks |
Дата | |
Msg-id | 803.1020109410@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Syscache/relcache invalidation event callbacks
|
Список | pgsql-hackers |
I'm planning to add a mechanism to backend/utils/cache/inval.c that will allow additional modules to register to get notification of syscache and relcache invalidation events. Right now, only the syscache and relcache get told about it --- but there's no reason we couldn't call additional routines here. The immediate thing I want this for is so that the namespace.c routines can safely use a cached list of OIDs for accessible namespaces. Without this cache, we'll have to repeatedly look up pg_namespace entries and check their USAGE privilege bits. That strikes me as a fairly expensive operation to have to do for each table, function, and operator name in every query, when in practice the results aren't going to be changing very often. I'd like to only do the lookups when search_path changes or we receive a notification of an update in pg_namespace. This mechanism would also allow us to solve the plpgsql-cached-plans problem that keeps coming up. If plpgsql registers a callback routine for relcache events, then it'll get a notification every time something happens to a relation schema. It could search its cached plans to see if there is any reference to that relation OID. If so, blow away the cached plan. (Or at least prevent it from being used again. There'd be some possibility of this happening for a plan that's currently in use, I believe, so you'd probably need to avoid discarding the plan until the active call is done.) We'll have the same problem with the PREPAREd-plan feature that Neil is working on, so it seems like time to do this. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: