From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Oleg Jurtšenko <oleg(dot)jurtsenko(at)fts(dot)ee>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5235: Segmentation fault under high load through JDBC |
Date: | 2009-12-09 04:47:49 |
Message-ID: | 4B1F2BF5.3070508@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
(resending with list cc'd)
Oleg Jurtšenko wrote:
> Core dump file are available here:
>
> www.fts.ee/pgsqldebug.tgz - with loging enabled
Well, it certainly looks recursive:
> #0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70, size=16) at mcxt.c:559
> #1 0x081bfc16 in ExecInitExpr (node=0x2b7f0078, parent=0x2da151a8) at execQual.c:4392
> #2 0x081c0d83 in ExecInitExpr (node=0x2b7f0050, parent=0x2da151a8) at execQual.c:4786
> #3 0x081bf769 in ExecInitExpr (node=0x2b7f0028, parent=0x2da151a8) at execQual.c:4280
> #4 0x081c0d83 in ExecInitExpr (node=0x2b7947e8, parent=0x2da151a8) at execQual.c:4786
> #5 0x081cc7ba in ExecInitIndexScan (node=0x2b794488, estate=0x2da15018, eflags=0) at nodeIndexscan.c:536
> #6 0x081b7b08 in ExecInitNode (node=0x2b794488, estate=0x2da15018, eflags=0) at execProcnode.c:179
> #7 0x081b487d in InitPlan (queryDesc=0x2da13040, eflags=0) at execMain.c:835
> #8 0x081b3be8 in standard_ExecutorStart (queryDesc=0x2da13040, eflags=0) at execMain.c:219
> #9 0x081b3a67 in ExecutorStart (queryDesc=0x2da13040, eflags=0) at execMain.c:148
> #10 0x081dc566 in _SPI_pquery (queryDesc=0x2da13040, fire_triggers=1 '\001', tcount=1) at spi.c:2010
> #11 0x081dc1de in _SPI_execute_plan (plan=0x2b793c18, paramLI=0x2da13018, snapshot=0x0, crosscheck_snapshot=0x0, read_only=0 '\0', fire_triggers=1 '\001', tcount=1) at spi.c:1834
> #12 0x081d9830 in SPI_execute_plan (plan=0x2b793c18, Values=0x2da11238, Nulls=0x2da11248 "nn", read_only=0 '\0', tcount=1) at spi.c:392
> #13 0x28a60023 in exec_stmt_execsql (estate=0xbfa00ebc, stmt=0x2b7f9948) at pl_exec.c:2781
> #14 0x28a5d4dd in exec_stmt (estate=0xbfa00ebc, stmt=0x2b7f9948) at pl_exec.c:1297
> #15 0x28a5d25d in exec_stmts (estate=0xbfa00ebc, stmts=0x2b7f9850) at pl_exec.c:1200
> #16 0x28a5ce2f in exec_stmt_block (estate=0xbfa00ebc, block=0x2b7f9ef0) at pl_exec.c:1012
> #17 0x28a5b91c in plpgsql_exec_function (func=0x2b787d28, fcinfo=0xbfa01000) at pl_exec.c:315
> #18 0x28a57541 in plpgsql_call_handler (fcinfo=0xbfa01000) at pl_handler.c:95
> #19 0x081bae61 in ExecMakeFunctionResultNoSets (fcache=0x2b64d218, econtext=0x2c7bc390, isNull=0xbfa012df "", isDone=0x0) at execQual.c:1752
> #20 0x28a6335c in exec_eval_simple_expr (estate=0xbfa0147c, expr=0x2b7f9998, result=0xbfa012a8, isNull=0xbfa012df "", rettype=0xbfa012e0) at pl_exec.c:4450
> #21 0x28a629e5 in exec_eval_expr (estate=0xbfa0147c, expr=0x2b7f9998, isNull=0xbfa012df "", rettype=0xbfa012e0) at pl_exec.c:4061
> #22 0x28a6154a in exec_assign_expr (estate=0xbfa0147c, target=0x2da0b118, expr=0x2b7f9998) at pl_exec.c:3428
> #23 0x28a5d633 in exec_stmt_assign (estate=0xbfa0147c, stmt=0x2b7f9980) at pl_exec.c:1345
> #24 0x28a5d357 in exec_stmt (estate=0xbfa0147c, stmt=0x2b7f9980) at pl_exec.c:1237
> #25 0x28a5d25d in exec_stmts (estate=0xbfa0147c, stmts=0x2b7f9850) at pl_exec.c:1200
> #26 0x28a5ce2f in exec_stmt_block (estate=0xbfa0147c, block=0x2b7f9ef0) at pl_exec.c:1012
> #27 0x28a5b91c in plpgsql_exec_function (func=0x2b787d28, fcinfo=0xbfa015c0) at pl_exec.c:315
> #28 0x28a57541 in plpgsql_call_handler (fcinfo=0xbfa015c0) at pl_handler.c:95
... blah blah ...
> #14169 0x081bacf6 in ExecMakeFunctionResult (fcache=0x2b64d218, econtext=0x2b64d110, isNull=0xbfbfdb8f "", isDone=0x0) at execQual.c:1685
> #14170 0x081bb631 in ExecEvalFunc (fcache=0x2b64d218, econtext=0x2b64d110, isNull=0xbfbfdb8f "", isDone=0x0) at execQual.c:2116
> #14171 0x28a6335c in exec_eval_simple_expr (estate=0xbfbfdd2c, expr=0x2b7f9998, result=0xbfbfdb58, isNull=0xbfbfdb8f "", rettype=0xbfbfdb90) at pl_exec.c:4450
> #14172 0x28a629e5 in exec_eval_expr (estate=0xbfbfdd2c, expr=0x2b7f9998, isNull=0xbfbfdb8f "", rettype=0xbfbfdb90) at pl_exec.c:4061
> #14173 0x28a6154a in exec_assign_expr (estate=0xbfbfdd2c, target=0x2b6464d8, expr=0x2b7f9998) at pl_exec.c:3428
> #14174 0x28a5d633 in exec_stmt_assign (estate=0xbfbfdd2c, stmt=0x2b7f9980) at pl_exec.c:1345
> #14175 0x28a5d357 in exec_stmt (estate=0xbfbfdd2c, stmt=0x2b7f9980) at pl_exec.c:1237
> #14176 0x28a5d25d in exec_stmts (estate=0xbfbfdd2c, stmts=0x2b7f9850) at pl_exec.c:1200
> #14177 0x28a5ce2f in exec_stmt_block (estate=0xbfbfdd2c, block=0x2b7f9ef0) at pl_exec.c:1012
> #14178 0x28a5b91c in plpgsql_exec_function (func=0x2b787d28, fcinfo=0xbfbfdea4) at pl_exec.c:315
> #14179 0x28a57541 in plpgsql_call_handler (fcinfo=0xbfbfdea4) at pl_handler.c:95
> #14180 0x081bacf6 in ExecMakeFunctionResult (fcache=0x2b6197c0, econtext=0x2b619330, isNull=0xbfbfe344 "<E8>8<D1>*(9<D1>*\027", isDone=0xbfbfe120) at execQual.c:1685
> #14181 0x081bb631 in ExecEvalFunc (fcache=0x2b6197c0, econtext=0x2b619330, isNull=0xbfbfe344 "<E8>8<D1>*(9<D1>*\027", isDone=0xbfbfe120) at execQual.c:2116
> #14182 0x081ba291 in ExecEvalFuncArgs (fcinfo=0xbfbfe1a4, argList=0x2b619c40, econtext=0x2b619330) at execQual.c:1216
> #14183 0x081ba834 in ExecMakeFunctionResult (fcache=0x2b6193b8, econtext=0x2b619330, isNull=0x2b61a0d8 "", isDone=0x2b61a170) at execQual.c:1463
> #14184 0x081bb631 in ExecEvalFunc (fcache=0x2b6193b8, econtext=0x2b619330, isNull=0x2b61a0d8 "", isDone=0x2b61a170) at execQual.c:2116
> #14185 0x081c1024 in ExecTargetList (targetlist=0x2b61a158, econtext=0x2b619330, values=0x2b61a0c8, isnull=0x2b61a0d8 "", itemIsDone=0x2b61a170, isDone=0xbfbfe4f0) at execQual.c:5007
> #14186 0x081c14cd in ExecProject (projInfo=0x2b61a0e8, isDone=0xbfbfe4f0) at execQual.c:5222
> #14187 0x081c1623 in ExecScan (node=0x2b6192a8, accessMtd=0x81d5120 <SubqueryNext>) at execScan.c:143
> #14188 0x081d516a in ExecSubqueryScan (node=0x2b6192a8) at nodeSubqueryscan.c:85
> #14189 0x081b7f9e in ExecProcNode (node=0x2b6192a8) at execProcnode.c:381
> #14190 0x081b598e in ExecutePlan (estate=0x2b619018, planstate=0x2b6192a8, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, dest=0x28bc4420) at execMain.c:1504
> #14191 0x081b3d53 in standard_ExecutorRun (queryDesc=0x2b789e40, direction=ForwardScanDirection, count=0) at execMain.c:309
> #14192 0x081b3c66 in ExecutorRun (queryDesc=0x2b789e40, direction=ForwardScanDirection, count=0) at execMain.c:258
> #14193 0x082958a7 in PortalRunSelect (portal=0x2ab68018, forward=1 '\001', count=0, dest=0x28bc4420) at pquery.c:953
> #14194 0x082955c0 in PortalRun (portal=0x2ab68018, count=2147483647, isTopLevel=1 '\001', dest=0x28bc4420, altdest=0x28bc4420, completionTag=0xbfbfe7d4 "") at pquery.c:779
> #14195 0x0829155f in exec_execute_message (portal_name=0x28bc4018 "", max_rows=2147483647) at postgres.c:1928
> #14196 0x08293e23 in PostgresMain (argc=4, argv=0x28b3b890, username=0x28b3b7c0 "tad") at postgres.c:3671
> #14197 0x0825e2d0 in BackendRun (port=0x28b2f600) at postmaster.c:3447
> #14198 0x0825d7b3 in BackendStartup (port=0x28b2f600) at postmaster.c:3061
> #14199 0x0825ad4a in ServerLoop () at postmaster.c:1387
> #14200 0x0825a466 in PostmasterMain (argc=3, argv=0xbfbfec2c) at postmaster.c:1040
> #14201 0x081ea4e5 in main (argc=3, argv=0xbfbfec2c) at main.c:188
Recursion within PL/PgSQL?
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-12-09 04:59:32 | Re: BUG #5235: Segmentation fault under high load through JDBC |
Previous Message | Tom Lane | 2009-12-09 04:08:34 | Re: BUG #5235: Segmentation fault under high load through JDBC |