I wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
>> 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...
> I think it's not a refcount issue, or at least not solely that. As best
> I can tell, there's a stack clobber involved, because gdb can't make sense
> of the stack after the exception hits. I've been trying to localize it
> more closely, but it's slow going because Apple's copy of python doesn't
> include debug symbols.
Fortunately, Apple still has the source code for that package archived at
www.opensource.apple.com, so after a bit of hair-pulling I was able to
build a version with debug symbols. And (may I have the envelope please)
you're right: it is a refcount issue. Take a look at what
PLy_modify_tuple does with plntup, and note that the "TD[\"new\"] is not a
dictionary" error is intentionally triggered by the plpython_trigger test.
So we have a prematurely-freed dictionary item apparently available for
recycling even though it's still part of the calling function's parsetree.
It's still like that in HEAD, too.
Will fix it shortly. I wonder though if there are any more thinkos like
this one :-(
BTW, isn't plstr totally dead code?
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
