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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
