Обсуждение: PlPython bug in 9.0/8.4.4

The way to reproduce:

CREATE OR REPLACE FUNCTION foobar(a integer[])
RETURNS SETOF int8 AS
$$    def getplan(name, query, args):        if SD.has_key(name):            plpy.warning("Using cached plan %s" %
name)           return SD[name]
 
        plpy.warning("Prepare plan %s" % name);        plan = plpy.prepare(query, args)        plpy.warning("Plan %s
prepared"% name);        SD[name] = plan        return plan
 
    for s in a:        userPlan = getplan('fooplan', 'select 1', []);        rrr =  plpy.execute(plan, [])  # variable
planisn't defined!        ret = s        yield ret
 
$$
LANGUAGE 'plpythonu';

On 9.0beta2 (instead of correct message "<type 'exceptions.NameError'>: global 
name 'plan' is not defined"):
postgres=#  select foobar('{1,2,3}');
WARNING:  Prepare plan fooplan
CONTEXT:  PL/Python function "foobar"
WARNING:  PL/Python: plpy.SPIError: unrecognized error in PLy_spi_prepare
CONTEXT:  PL/Python function "foobar"
ERROR:  error fetching next item from iterator
CONTEXT:  PL/Python function "foobar"
postgres=#  select foobar('{1,2,3}');
server closed the connection unexpectedly        This probably means the server terminated abnormally        before or
whileprocessing the request.
 
The connection to the server was lost. Attempting reset: Failed.
!?>

Log:
TRAP: FailedAssertion("!(edata->elevel == 20)", File: "elog.c", Line: 1280)

8.4.4 haves essentially the same bug.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

Teodor Sigaev <teodor@sigaev.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