Skip site navigation (1) Skip section navigation (2)

Syscache/relcache invalidation event callbacks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Syscache/relcache invalidation event callbacks
Date: 2002-04-29 19:43:30
Message-ID: 803.1020109410@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: 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

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-04-29 20:06:48
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Marc G. FournierDate: 2002-04-29 18:52:19
Subject: Re: Vote totals for SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group