Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> ISTM the caching code for plpythonu trigger functions has been broken
> for some time. The bug seem to be that PLy_procedure_get looks up the
> function in a separate cache for trigger functions (PLy_trigger_cache)
> but still only uses the function oid for lookup.
> So the same function can be looked up for two tables and when the cached
> entry originally refers to the old table that has been dropped we see
> the above error.
> The fix seems tob e to make PLy_trigger_cache have a key of (reloid,
> fn_oid) instead of just fn_oid.
If there's anything in either the cache entry itself or the function's
other persistent state that is dependent on which table it's attached
to, then yeah, obviously. But another conceivable solution would be to
not store any such information.
In a quick look, it seems like the "PLyTypeInfo result" field might
depend on which table the trigger is attached to, so unless we can
get along without that, we'll need to expand the hash key.
Actually I'm wondering a bit why there are two hash tables at all.
Seems like one table with a hash key of (fnoid, reloid) could be
used, with the convention of reloid = 0 for non-trigger calls.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
