8.0.0rc1 core dump with PREPARE in a function - Mailing list pgsql-bugs
From | Michael Fuhr |
---|---|
Subject | 8.0.0rc1 core dump with PREPARE in a function |
Date | |
Msg-id | 20041211174950.GA39618@winnie.fuhr.org Whole thread Raw |
Responses |
Re: 8.0.0rc1 core dump with PREPARE in a function
|
List | pgsql-bugs |
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) atspi.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/
pgsql-bugs by date: