Andres Freund <and...@2ndquadrant.com> writes: > On 2014-03-24 00:54:31 -0400, Tom Lane wrote: >> Some bisection tests say that it started failing after commit >> 17dee323e7ff67863582f279e415a8228e0b99cd. No idea why, atm.
> I can't really see why that'd would cause any such failure either. One > thing that I'd try is is just disabling the caching, to rule out > problems around that. > Do I understand correctly that you have a machine where you can > reproduce this on? And it can just be reproduced on OSX with python 2.3? It's 100% reproducible on prairiedog, which is a Mac Cube running Tiger, and using the version of python that came with Tiger (2.3.5 :-(). It seems not impossible that we're looking at a long-since-fixed python bug, but the fact that that specific commit made it appear or disappear is troubling. One thing I was wondering about, not being a python user: why is it okay to use non-unique names for the python procedures? That is, PLy_procedure_munge_source() does a "def" with a procedure name constructed thus: rv = snprintf(procName, sizeof(procName), "__plpython_procedure_%s_%u", NameStr(procStruct->proname), fn_oid); while at the plpython level we're of the opinion that trigger functions applied to different relations need separate cache entries. How can it be OK for separate cache entries to reference the same "def" name? I tried modifying the code like this: rv = snprintf(procName, sizeof(procName), "__plpython_%sprocedure_%s_%u_%u", is_trigger ? "trigger_" : "", NameStr(procStruct->proname), fn_oid, fn_rel); and that didn't make this crash go away, but it sure looks like the existing code could cause problems for somebody. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers