Re: PlPython bug in 9.0/8.4.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: PlPython bug in 9.0/8.4.4
Date: 2010-06-08 16:14:37
Message-ID: 6099.1276013677@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> The way to reproduce:

Well, of course plpython's error handling is fundamentally brain dead.

The immediate problem here seems to be that the PLy_error_in_progress
struct is stored in a memory context that's been cleared by the time
that control gets to the place in PLy_procedure_call() where we try to
re-throw it. It might be that we need to copy the ErrorData into a
less short-lived context than the one that's current when
PLy_spi_prepare is called. Or maybe PLy_function_handler just needs
to think a bit harder about where it has to check PLy_error_in_progress
and/or where it's safe to shut down the SPI call. Or all of the above.

Really I'd like to see that whole mess thrown out and rewritten.
pltcl and plperl got rid of static error state years ago, because of
essentially this same type of risk.

> 8.4.4 haves essentially the same bug.

I'm sure it goes all the way back.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-06-08 16:23:56 Re: 3rd time is a charm.....right sibling is not next child crash.
Previous Message Stephen Frost 2010-06-08 15:51:09 Re: Functional dependencies and GROUP BY