Re: Minimum supported version of Python?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Minimum supported version of Python?
Date: 2014-03-25 19:08:16
Message-ID: 28345.1395774496@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-03-25 20:34:58 Re: gsoc knn spgist
Previous Message Tom Lane 2014-03-25 18:58:54 Re: Still something fishy in the fastpath lock stuff