Syscache/relcache invalidation event callbacks - Mailing list pgsql-hackers

From Tom Lane
Subject Syscache/relcache invalidation event callbacks
Date
Msg-id 803.1020109410@sss.pgh.pa.us
Whole thread Raw
Responses Re: Syscache/relcache invalidation event callbacks  (Karel Zak <zakkr@zf.jcu.cz>)
List 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 by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Thomas Lockhart
Date:
Subject: Re: Vote totals for SET in aborted transaction