PostgreSQL 8.0.0rc1 (CVS HEAD)
Solaris 9, FreeBSD 4.11-PRERELEASE

I can consistenly produce a core dump by calling a function that
executes PREPARE...INSERT or PREPARE...UPDATE, then calling it again.
I haven't been able to produce a core dump with PREPARE...SELECT.
When I call the function the second time I was expecting all cases
to complain that the prepared statement already exists, but the
INSERT and UPDATE cases dump core, while the SELECT case makes the
following complaint:

ERROR: XX000: unrecognized node type: 656
CONTEXT: SQL statement "PREPARE foosel (TEXT) AS SELECT name FROM foo WHERE name = $1"
PL/pgSQL function "fooprepare" line 2 at SQL statement
LOCATION: pull_up_subqueries, prepjointree.c:375

Here a test case that reproduces the core dump:

CREATE TABLE foo (name TEXT);

CREATE FUNCTION fooprepare() RETURNS void AS $$
BEGIN
PREPARE fooins (TEXT) AS INSERT INTO foo VALUES ($1);
RETURN;
END;
$$ LANGUAGE plpgsql;

SELECT fooprepare();
SELECT fooprepare();
server closed the connection unexpectedly

The server logs "terminated by signal 11". Here's a stack trace:

#0 expand_targetlist (tlist=0x83500e0, command_type=3, result_relation=1, range_table=0x83532e0) at preptlist.c:154
154 if (!resdom->resjunk && resdom->resno == attrno)
(gdb) bt
#0 expand_targetlist (tlist=0x83500e0, command_type=3, result_relation=1, range_table=0x83532e0) at preptlist.c:154
#1 0x81411c3 in preprocess_targetlist (tlist=0x83500e0, command_type=3, result_relation=1, range_table=0x83532e0) at preptlist.c:67
#2 0x813d0b8 in grouping_planner (parse=0x8353258, tuple_fraction=0) at planner.c:668
#3 0x813cc12 in subquery_planner (parse=0x8353258, tuple_fraction=0) at planner.c:326
#4 0x813c95e in planner (parse=0x8353258, isCursor=0, cursorOptions=0, boundParams=0x0) at planner.c:129
#5 0x816e48b in pg_plan_query (querytree=0x8353258, boundParams=0x0) at postgres.c:647
#6 0x816e52d in pg_plan_queries (querytrees=0x83500a0, boundParams=0x0, needSnapshot=0 '\000') at postgres.c:715
#7 0x80e4f04 in PrepareQuery (stmt=0x8353160) at prepare.c:94
#8 0x81731a5 in ProcessUtility (parsetree=0x8353160, params=0x0, dest=0x8278a48, completionTag=0x0) at utility.c:591
#9 0x8116036 in _SPI_execute_plan (plan=0x8353018, Values=0x834a070, Nulls=0x834a080 "", snapshot=0x0, crosscheck_snapshot=0x0, read_only=0 '\000', tcount=0)
at spi.c:1441
#10 0x8114929 in SPI_execute_plan (plan=0x8353018, Values=0x834a070, Nulls=0x834a080 "", read_only=0 '\000', tcount=0) at spi.c:334
#11 0x28515e6f in exec_stmt_execsql (estate=0xbfbfebd0, stmt=0x82db6f0) at pl_exec.c:2146
#12 0x28514845 in exec_stmt (estate=0xbfbfebd0, stmt=0x82db6f0) at pl_exec.c:1099
#13 0x2851465e in exec_stmts (estate=0xbfbfebd0, stmts=0x82db700) at pl_exec.c:1015
#14 0x28514592 in exec_stmt_block (estate=0xbfbfebd0, block=0x82c0e40) at pl_exec.c:970
#15 0x2851382e in plpgsql_exec_function (func=0x82c3e00, fcinfo=0xbfbfecb8) at pl_exec.c:336
#16 0x285107d2 in plpgsql_call_handler (fcinfo=0xbfbfecb8) at pl_handler.c:127
#17 0x8106b68 in ExecMakeFunctionResult (fcache=0x8342210, econtext=0x8342188,
isNull=0xbfbfede7 "\b(î¿¿\222\231\020\b(#4\b@#4\b\210!4\b($4\b8$4\bH $4\bTî¿¿yï\035\b", isDone=0x8342448) at execQual.c:1038
#18 0x8107333 in ExecEvalFunc (fcache=0x8342210, econtext=0x8342188, isNull=0xbfbfede7 "\b(î¿¿\222\231\020\b(#4\b@#4\b\210!4\b($4\b8$4\bH $4\bTî¿¿yï\035\b",
isDone=0x8342448) at execQual.c:1455
#19 0x8109787 in ExecTargetList (targetlist=0x8342328, targettype=0x8342340, econtext=0x8342188, values=0x8342428, nulls=0x8342438 "", itemIsDone=0x8342448,
isDone=0xbfbfee54) at execQual.c:3433
#20 0x8109992 in ExecProject (projInfo=0x8342400, isDone=0xbfbfee54) at execQual.c:3579
#21 0x81110a7 in ExecResult (node=0x8342100) at nodeResult.c:155
#22 0x81058cd in ExecProcNode (node=0x8342100) at execProcnode.c:292
#23 0x81045d4 in ExecutePlan (estate=0x8342018, planstate=0x8342100, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, dest=0x8336750)
at execMain.c:1060
#24 0x8103bf4 in ExecutorRun (queryDesc=0x8311840, direction=ForwardScanDirection, count=0) at execMain.c:226
#25 0x8171f2e in PortalRunSelect (portal=0x8340018, forward=1, count=2147483647, dest=0x8336750) at pquery.c:746
#26 0x8171c4b in PortalRun (portal=0x8340018, count=2147483647, dest=0x8336750, altdest=0x8336750, completionTag=0xbfbff088 "") at pquery.c:561
#27 0x816e805 in exec_simple_query (query_string=0x8336018 "select fooprepare();") at postgres.c:933
#28 0x8170cd3 in PostgresMain (argc=4, argv=0x82c6258, username=0x82c6238 "mfuhr") at postgres.c:3007
#29 0x814c4dd in BackendRun (port=0x82dc600) at postmaster.c:2817
#30 0x814bd1e in BackendStartup (port=0x82dc600) at postmaster.c:2453
#31 0x814a2aa in ServerLoop () at postmaster.c:1198
#32 0x8149cf2 in PostmasterMain (argc=3, argv=0xbfbffc78) at postmaster.c:917
#33 0x811dff9 in main (argc=3, argv=0xbfbffc78) at main.c:268

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

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

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
I think this is a variant of the same problem recently detected with
DECLARE CURSOR, ie, PREPARE had better copy the source parsetree before
letting the planner touch it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly