On 2014-03-25 15:08:16 -0400, Tom Lane wrote:
> Andres Freund <andres@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.
Yea, agreed.
If there's a refcounting bug inside python somewhere (which is easy to
trigger in python's C interface), it could be excerbated by that change,
since it frees/compiles functions more frequently. But I'd very much
like more evidence of this...
> 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:
That should be fine. The name isn't really meaningful for anything but
debugging. It's perfectly fine to overwrite functions in a namespace and
call them via reference in python.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services