On 2014-03-25 15:08:16 -0400, Tom Lane wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
