help with PL/PgSQL bug - Mailing list pgsql-hackers
From | Neil Conway |
---|---|
Subject | help with PL/PgSQL bug |
Date | |
Msg-id | 1042247302.748.46.camel@tokyo Whole thread Raw |
Responses |
Re: help with PL/PgSQL bug
|
List | pgsql-hackers |
Folks, Someone contacted me in IRC about a bug in PL/PgSQL. I've confirmed that the example SQL they sent me causes a segfault on my machine (CVS HEAD), but I've so far not had a lot of success tracking down the exact cause of the problem. Backtrace: #0 0x403ed17a in compatible_tupdesc (td1=0x82c621c, td2=0x0) at pl_exec.c:3715 #1 0x403eabb6 in exec_stmt_return_next (estate=0xbfffec50, stmt=0x82d2e68) at pl_exec.c:1630 #2 0x403e9f20 in exec_stmt (estate=0xbfffec50, stmt=0x82d2e68) at pl_exec.c:949 #3 0x403e9e09 in exec_stmts (estate=0xbfffec50, stmts=0x82d29c8) at pl_exec.c:873 #4 0x403ea486 in exec_stmt_fori (estate=0xbfffec50, stmt=0x82d2eb0) at pl_exec.c:1276 #5 0x403e9ed4 in exec_stmt (estate=0xbfffec50, stmt=0x82d2eb0) at pl_exec.c:929 #6 0x403e9e09 in exec_stmts (estate=0xbfffec50, stmts=0x82d2580) at pl_exec.c:873 #7 0x403ea486 in exec_stmt_fori (estate=0xbfffec50, stmt=0x82d2f28) at pl_exec.c:1276 #8 0x403e9ed4 in exec_stmt (estate=0xbfffec50, stmt=0x82d2f28) at pl_exec.c:929 #9 0x403e9e09 in exec_stmts (estate=0xbfffec50, stmts=0x82d2148) at pl_exec.c:873 #10 0x403ea60b in exec_stmt_fors (estate=0xbfffec50, stmt=0x82d2fa0) at pl_exec.c:1386 #11 0x403e9ee2 in exec_stmt (estate=0xbfffec50, stmt=0x82d2fa0) at pl_exec.c:933 #12 0x403e9e09 in exec_stmts (estate=0xbfffec50, stmts=0x82d1ec0) at pl_exec.c:873 #13 0x403e9ca7 in exec_stmt_block (estate=0xbfffec50, block=0x82d3078) at pl_exec.c:829 #14 0x403e910b in plpgsql_exec_function (func=0x82a9b70, fcinfo=0xbfffed50) at pl_exec.c:323 #15 0x403e6c94 in plpgsql_call_handler (fcinfo=0xbfffed50) at pl_handler.c:133 #16 0x080e89c2 in ExecMakeTableFunctionResult (funcexpr=0x82c6a2c, econtext=0x82c5d38, expectedDesc=0x82c621c, returnDesc=0xbfffee38) at execQual.c:993 #17 0x080f03d2 in FunctionNext (node=0x82c5bc0) at nodeFunctionscan.c:78 #18 0x080ea002 in ExecScan (node=0x82c5bc0, accessMtd=0x80f0368 <FunctionNext>) at execScan.c:94 #19 0x080f041f in ExecFunctionScan (node=0x82c5bc0) at nodeFunctionscan.c:127 #20 0x080e7606 in ExecProcNode (node=0x82c5bc0) at execProcnode.c:324 #21 0x080e62c1 in ExecutePlan (estate=0x82c5aec, planstate=0x82c5bc0, operation=CMD_SELECT, numberTuples=0, direction=137126428, destfunc=0x82c5cc4) at execMain.c:926 #22 0x080e5936 in ExecutorRun (queryDesc=0x82c2f3c, direction=ForwardScanDirection, count=0) at execMain.c:220 #23 0x0813b05b in ProcessQuery (parsetree=0x82a4d70, plan=0x82c2f3c, dest=Remote, completionTag=0xbffff000 "") at pquery.c:205 #24 0x0813975d in pg_exec_query_string (query_string=0xbffff000, dest=Remote, parse_context=0x827026c) at postgres.c:838 #25 0x0813a6f4 in PostgresMain (argc=4, argv=0xbffff270, username=0x826b841 "nconway") at postgres.c:2013 #26 0x0811f2a2 in DoBackend (port=0x826b710) at postmaster.c:2314 #27 0x0811ee1a in BackendStartup (port=0x826b710) at postmaster.c:1930 #28 0x0811df8d in ServerLoop () at postmaster.c:1017 #29 0x0811d9e9 in PostmasterMain (argc=1, argv=0x825eb08) at postmaster.c:796 #30 0x080fa390 in main (argc=1, argv=0xbffffbf4) at main.c:209 A SQL script that triggers the problem is attached. Any help on tracking down the problem would be much appreciated. Once this has been diagnosed and fixed, I think it's suitable for 7.3.2. Cheers, Neil
Attachment
pgsql-hackers by date: