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

From Tom Lane
Subject Re: Syscache/relcache invalidation event callbacks
Date
Msg-id 19687.1020174209@sss.pgh.pa.us
Whole thread Raw
In response to Re: Syscache/relcache invalidation event callbacks  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: Syscache/relcache invalidation event callbacks  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
Karel Zak <zakkr@zf.jcu.cz> writes:
>  I have a question, how I will know how changes are relevant for my 
>  query plan? IMHO is needful some hight-level API, like

>     list = ExtractQueryPlanOids( plan );
>     reg = RegisterOidsCallback( list, mycallback, mycallbackdata );

Yes, some kind of routine to extract all the referenced relation OIDs
in a plan tree would be a good idea.  I can provide that.  The inval
callback just tells you the OID of the relation that got flushed; it's
up to you to get from there to the plans you need to rebuild.  Perhaps
a hash table would work well.

BTW, the inval callback had better just mark the plans invalid, not
try to rebuild them right away.  I don't think it's safe to try to
do more database accesses while we're in the relcache invalidation
path.  "Rebuild plan on next attempted use" seems like a better idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: shibu.kurian@orbitech.co.in
Date:
Subject: Graphical Aplication for visualising postgresql internals
Next
From: Tom Lane
Date:
Subject: Re: [RFC] Set Returning Functions