I'm not entirely sure if this is a bug. Basically I have a python
function that needs to create new functions. I intended on doing this
through the plpy.excute("create function...")

Unfortunately this crashes postmaster v8.0.3. I'm kind of bound to
this version - but it would be good to know if someone else can
replicate this error (i.e. if it's ok in other versions) or if it is
infact a bug or if I'm just doing something stupid.

A simple example:

I want to create a (plpgsql) function (an example definition as follows):
CREATE or REPLACE FUNCTION blah(inp int) RETURNS int AS $$ BEGIN
return inp; END; $$ LANGUAGE 'plpgsql';

From a plpythonu function: that is:
CREATE OR REPLACE FUNCTION testpythonexecute() RETURNS text AS $BODY$
plpy.execute('CREATE or REPLACE FUNCTION blah(inp int) RETURNS int AS
$$ BEGIN return inp; END; $$ LANGUAGE ''plpgsql'';')
return 'done'
$BODY$
LANGUAGE 'plpythonu';

A small postmaster trace:

CONTEXT: compile of PL/pgSQL function "blah" near line 0
SQL statement "CREATE or REPLACE FUNCTION blah(inp int)
RETURNS int AS $$ BEGIN return inp; END; $$ LANGUAGE plpgsql;"
*** glibc detected *** postgres: research test [local] SELECT: free():
invalid pointer: 0xb72c83f8 ***
======= Backtrace: =========
/lib/libc.so.6[0x79cdf1]
/lib/libc.so.6(cfree+0x90)[0x7a0430]
/home/research/pgsql/lib/plpython.so[0x2584c4]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x165c)[0x61d5f6c]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x61dacdf]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x61dbb2f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0x61dbbb3]
/home/research/pgsql/lib/plpython.so[0x25ac2e]
/home/research/pgsql/lib/plpython.so[0x25ca77]
/home/research/pgsql/lib/plpython.so(plpython_call_handler+0xf6)[0x25cd66]
postgres: research test [local] SELECT(ExecMakeFunctionResult+0x213)[0x812b303]
postgres: research test [local] SELECT(ExecProject+0xd1)[0x81293e1]
postgres: research test [local] SELECT(ExecResult+0x5d)[0x81362dd]
postgres: research test [local] SELECT(ExecProcNode+0xdd)[0x8128b6d]
postgres: research test [local] SELECT(ExecutorRun+0x2ad)[0x812788d]
postgres: research test [local] SELECT[0x81a7480]
postgres: research test [local] SELECT(PortalRun+0x296)[0x81a8116]
postgres: research test [local] SELECT(exec_simple_query+0x20c)[0x81a41ec]
postgres: research test [local] SELECT(PostgresMain+0x1213)[0x81a5813]
postgres: research test [local] SELECT[0x8174d56]
postgres: research test [local] SELECT(PostmasterMain+0xef0)[0x81765b0]
postgres: research test [local] SELECT(main+0x22e)[0x8144dbe]
/lib/libc.so.6(__libc_start_main+0xe0)[0x74af70]
postgres: research test [local] SELECT[0x8076e01]

..........

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"blay bloo" <blaybloo@googlemail.com> writes:
> Unfortunately this crashes postmaster v8.0.3.
> ...
> /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x165c)[0x61d5f6c]

I think the short answer is that PG 8.0.x doesn't support python 2.5,
period. Why do you feel that you must use a hoary PG version but it's
OK to have a bleeding-edge Python in there?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster