Karel Zak <zakkr@zf.jcu.cz> writes:
> There must be possible define some callback specific data too, the
> callback maybe will search query in some own specific cache and it
> require some key.
Yeah, I have it set up similarly to on_proc_exit callbacks: when you
register the callback function you can also provide a Datum (typically
a pointer). But I'm not sure that there's any real value in this.
AFAICS, such callbacks are always going to be interested in looking
through a cache data structure of some kind, and so there will always
be global variables pointing to what they need to get to. (I'm
envisioning *one* callback function handling a whole cache, not a
callback for each entry!)
>> 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
> Hmm, it can depend on action, I can imagine:
> DROP TABLE tab;
> ERROR: mycallback(): can't rebuild the query used in PL/SQL function
> 'xyz'. Please drop this function first.
> ...table drop failed.
Nope, that is NOT okay.
(1) The drop might have been done by some other backend.
(2) Even if it was your own backend, the drop is already committed by the time you hear about it.
You invalidate the plan, and then when and if that function is called
again, you'll flag an error as a natural result of trying to recompute
the plan. No shortcuts.
(If we do want to prevent a drop in cases like this, it has to be done
via the kind of dependency mechanism that Rod is working on.)
> There can be one query cache and one cached planns checking only, for RI,
> SPI, PL/SQL, PREPARE/EXECUTE. Or not?
Hmm. Seems like it might be a good idea, but I'm not certain that all
of these have exactly the same requirements. If they can all share one
cache that'd definitely be a win.
regards, tom lane