BUG #6621: Constant Segmentation Faults in the Postmaster

From: kris(at)spiceworks(dot)com
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #6621: Constant Segmentation Faults in the Postmaster
Date: 2012-04-27 16:11:41
Message-ID: E1SNnll-0006li-JJ@wrigleys.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 6621
Logged by: Kris Bushover
Email address: kris(at)spiceworks(dot)com
PostgreSQL version: 9.1.3
Operating system: Red Hat Enterprise Linux Server release 6.2 (Santi
Description:

We have been getting constant segmentation faults (signal 11) when running
PostgreSQL 9.1. We have replaced the hardware (RAM), updated PG to the
latest version, and made changes to our configuration file as recommended by
EnterpriseDB.

I was able to get a core dump after the last fault, pasted below.

Core was generated by `postgres: dbuser db_production 10.10.11.66(46200)
EXPLAIN'.
Program terminated with signal 11, Segmentation fault.
#0 AllocSetAlloc (context=0x296f060, size=16) at aset.c:639
639 set->freelist[fidx] = (AllocChunk) chunk->aset;

(gdb) bt
#0 AllocSetAlloc (context=0x296f060, size=16) at aset.c:639
#1 0x000000000070b725 in MemoryContextAllocZeroAligned (context=0x296f060,
size=16) at mcxt.c:571
#2 0x00000000005b6ab5 in makeString (str=0x7f096602eb90 "@@") at
value.c:55
#3 0x000000000068c720 in generate_operator_name (operid=3636, arg1=3614,
arg2=3615) at ruleutils.c:7148
#4 0x000000000068f9f3 in get_oper_expr (node=0x2b55bc0,
context=0x7fffba0fbc10, showimplicit=<value optimized out>) at
ruleutils.c:5762
#5 get_rule_expr (node=0x2b55bc0, context=0x7fffba0fbc10,
showimplicit=<value optimized out>) at ruleutils.c:4920
#6 0x000000000068f948 in get_rule_expr (node=0x2b558d0,
context=0x7fffba0fbc10, showimplicit=<value optimized out>) at
ruleutils.c:5004
#7 0x000000000069385d in deparse_expression_pretty (expr=0x2b558d0,
dpcontext=0x2bae6f8, forceprefix=<value optimized out>, showimplicit=0
'\000', prettyFlags=0,
startIndent=0) at ruleutils.c:2118
#8 0x000000000051f434 in show_expression (node=0x2b558d0, qlabel=0x80ae9c
"Filter", planstate=<value optimized out>, ancestors=<value optimized out>,
useprefix=0 '\000', es=0x7fffba0fc4f0) at explain.c:1322
#9 0x00000000005201d1 in ExplainNode (planstate=0x2b8a400,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1045
#10 0x0000000000520109 in ExplainNode (planstate=0x2b8a190,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1197
#11 0x0000000000520109 in ExplainNode (planstate=0x2b89ef0,
ancestors=0x2b5f3e0, relationship=0x80afc1 "Subquery", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1197
#12 0x00000000005204b9 in ExplainNode (planstate=0x2b89620,
ancestors=0x2b5f3e0, relationship=0x80b02c "Member", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1234
#13 0x00000000005218a5 in ExplainMemberNodes (plans=<value optimized out>,
planstates=<value optimized out>, ancestors=0x2b5f3e0, es=0x7fffba0fc4f0) at
explain.c:1697
#14 0x00000000005201f3 in ExplainNode (planstate=0x2b78e70,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1229
#15 0x0000000000520109 in ExplainNode (planstate=0x2b78340,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1197
#16 0x0000000000520109 in ExplainNode (planstate=0x2b77a50,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1197
#17 0x0000000000520109 in ExplainNode (planstate=0x2b71460,
ancestors=0x2b5f3e0, relationship=0x80afb5 "Outer", plan_name=<value
optimized out>, es=0x7fffba0fc4f0)
at explain.c:1197
#18 0x0000000000520109 in ExplainNode (planstate=0x2b711f0,
ancestors=0x2b5f3e0, relationship=0x0, plan_name=<value optimized out>,
es=0x7fffba0fc4f0)
at explain.c:1197
#19 0x0000000000521259 in ExplainOnePlan (plannedstmt=0x2b5b310,
es=0x7fffba0fc4f0, queryString=<value optimized out>, params=0x0) at
explain.c:404
#20 0x000000000052170b in ExplainOneQuery (stmt=0x2981830,
queryString=<value optimized out>, params=0x0, dest=0x29709e8) at
explain.c:296
#21 ExplainQuery (stmt=0x2981830, queryString=<value optimized out>,
params=0x0, dest=0x29709e8) at explain.c:202
#22 0x0000000000634137 in PortalRunUtility (portal=0x296c8a0,
utilityStmt=0x2981830, isTopLevel=1 '\001', dest=0x29709e8,
completionTag=0x7fffba0fc5a0 "")
at pquery.c:1184
#23 0x00000000006353bd in FillPortalStore (portal=0x296c8a0, isTopLevel=1
'\001') at pquery.c:1058
#24 0x00000000006358ff in PortalRun (portal=0x296c8a0,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x2928ab0,
altdest=0x2928ab0,
completionTag=0x7fffba0fc920 "") at pquery.c:782
#25 0x00000000006331ee in exec_execute_message (argc=<value optimized out>,
argv=<value optimized out>, username=<value optimized out>) at
postgres.c:1963
#26 PostgresMain (argc=<value optimized out>, argv=<value optimized out>,
username=<value optimized out>) at postgres.c:3983
#27 0x00000000005f46c9 in BackendRun () at postmaster.c:3606
#28 BackendStartup () at postmaster.c:3291
#29 ServerLoop () at postmaster.c:1455
#30 0x00000000005f6e5c in PostmasterMain (argc=<value optimized out>,
argv=<value optimized out>) at postmaster.c:1116
#31 0x0000000000598a40 in main (argc=5, argv=0x28524d0) at main.c:199

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Frost 2012-04-27 16:18:41 Re: 9.1.3 backends getting stuck in 'startup'
Previous Message Jeff Frost 2012-04-27 16:07:46 9.1.3 backends getting stuck in 'startup'