Thread: postmaster core dump
I seem to have an unhappy postgresql:
(gdb) bt
#0 0xbd99871b in kill () from /usr/lib/libc.so.12
#1 0xbda217e7 in abort () from /usr/lib/libc.so.12
#2 0x0820c1fa in ExceptionalCondition ( conditionName=0x8298920 "!(batchno > hashtable->curbatch)",
errorType=0x823919f"FailedAssertion", fileName=0x82988e0 "/usr/src/local/pgsql/src/backend/executor/nodeHash.c",
lineNumber=675)at /usr/src/local/pgsql/src/backend/utils/error/assert.c:51
#3 0x08136c09 in ExecHashTableInsert (hashtable=0x83e9c9c, tuple=0x83e9ce8, hashvalue=4294941132) at
/usr/src/local/pgsql/src/backend/executor/nodeHash.c:679
#4 0x081363e1 in MultiExecHash (node=0x83e91b4) at /usr/src/local/pgsql/src/backend/executor/nodeHash.c:114
#5 0x0812c24f in MultiExecProcNode (node=0x83e91b4) at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:439
#6 0x0813707a in ExecHashJoin (node=0x83e65ac) at /usr/src/local/pgsql/src/backend/executor/nodeHashjoin.c:160
#7 0x0812c11a in ExecProcNode (node=0x83e65ac) at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:358
#8 0x081348f5 in agg_fill_hash_table (aggstate=0x83e62b4) at
/usr/src/local/pgsql/src/backend/executor/nodeAgg.c:911
#9 0x081345fb in ExecAgg (node=0x83e62b4) at /usr/src/local/pgsql/src/backend/executor/nodeAgg.c:681
#10 0x0812c152 in ExecProcNode (node=0x83e62b4) at /usr/src/local/pgsql/src/backend/executor/execProcnode.c:377
#11 0x0812aa2b in ExecutePlan (estate=0x83e601c, planstate=0x83e62b4, operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, dest=0x83d8d8c) at /usr/src/local/pgsql/src/backend/executor/execMain.c:1110
#12 0x08129dc7 in ExecutorRun (queryDesc=0x83db848, direction=ForwardScanDirection, count=0) at
/usr/src/local/pgsql/src/backend/executor/execMain.c:231
#13 0x081a89a3 in PortalRunSelect (portal=0x83e401c, forward=1 '\001', count=2147483647, dest=0x83d8d8c) at
/usr/src/local/pgsql/src/backend/tcop/pquery.c:797
#14 0x081a8758 in PortalRun (portal=0x83e401c, count=2147483647, dest=0x83d8d8c, altdest=0x83d8d8c,
completionTag=0xbfbfe1d0"") at /usr/src/local/pgsql/src/backend/tcop/pquery.c:648
#15 0x081a4c2f in exec_simple_query ( query_string=0x834501c "select timesliced, count(stats_id) from trans left j
/* * put the tuple into a temp file for later batches */ Assert(batchno >
hashtable->curbatch); ExecHashJoinSaveTuple(tuple, hashvalue,
&hashtable->innerBatchFile[batchno]);
(gdb) print batchno
$2 = 2
(gdb) print *hashtable
$3 = {nbuckets = 2063, buckets = 0x83f601c, nbatch = 16, curbatch = 3, nbatch_original = 16, nbatch_outstart = 16,
growEnabled= 1 '\001', totalTuples = 25998, innerBatchFile = 0x83f401c, outerBatchFile = 0x83f4068, hashfunctions =
0x83ea0a4,spaceUsed = 136816, spaceAllowed = 1048576, hashCxt = 0x835a648, batchCxt = 0x835a6d4}
cvs of 1 Sept, nodeHash.c v 1.94
Any thoughts?
Cheers,
Patrick
On Mon, Sep 19, 2005 at 06:12:54PM +0100, Patrick Welche wrote:
> #15 0x081a4c2f in exec_simple_query (
> query_string=0x834501c "select timesliced, count(stats_id) from trans left j
I just truncated one line early.. the query was:
# explain select timesliced, count(stats_id) from trans left join stats on stats_id=stats.id group by timesliced;
QUERY PLAN
-------------------------------------------------------------------------------HashAggregate
(cost=123718.66..123738.61rows=1596 width=8) -> Hash Left Join (cost=4143.88..115550.16 rows=1633701 width=8)
HashCond: ("outer".stats_id = "inner".id) -> Seq Scan on trans (cost=0.00..61341.01 rows=1633701 width=4)
-> Hash (cost=3292.30..3292.30 rows=123430 width=8) -> Seq Scan on stats (cost=0.00..3292.30
rows=123430width=8)
(6 rows)
Cheers,
Patrick
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> I seem to have an unhappy postgresql:
Let's see a test case, not a stack trace.
regards, tom lane
On Mon, Sep 19, 2005 at 03:59:35PM -0400, Tom Lane wrote:
> Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> > I seem to have an unhappy postgresql:
>
> Let's see a test case, not a stack trace.
I haven't set up the minimalist test case yet, but the 2 tables involved
are incredibly simple. stats.id is an integer primary key, trans.stats_id
points to it. You just need a query which uses a HashJoin. This time, no
core dump, however:
transatlantic=# set enable_hashjoin=on;
SET
transatlantic=# select timeslice,count(stats_id) from trans,stats where trans.stats_id=stats.id group by
timeslice;timeslice| count
-----------+-------
(0 rows)
transatlantic=# set enable_hashjoin=off;
SET
transatlantic=# select timeslice,count(stats_id) from trans,stats where trans.stats_id=stats.id group by timeslice;
timeslice | count
---------------------+-------2005-08-28 00:00:00 | 5862005-08-28 00:00:01 | 3782005-08-28 00:20:00 | 878
...
So, no results with enable_hashjoin=on.
Broken:
QUERY PLAN
--------------------------------------------------------------------------------------GroupAggregate
(cost=326296.78..338449.98rows=97067 width=12) -> Sort (cost=326296.78..329943.40 rows=1458648 width=12) Sort
Key:stats.timeslice -> Hash Join (cost=4203.88..108728.93 rows=1458648 width=12) Hash Cond:
("outer".stats_id= "inner".id) -> Seq Scan on trans (cost=0.00..59706.48 rows=1458648 width=4)
-> Hash (cost=3292.30..3292.30 rows=123430 width=12) -> Seq Scan on stats (cost=0.00..3292.30
rows=123430width=12)
Working:
QUERY PLAN
---------------------------------------------------------------------------------------------------GroupAggregate
(cost=506460.77..518613.97rows=97067 width=12) -> Sort (cost=506460.77..510107.39 rows=1458648 width=12) Sort
Key:stats.timeslice -> Merge Join (cost=263024.32..288892.93 rows=1458648 width=12) Merge Cond:
("outer".id= "inner".stats_id) -> Index Scan using stats_pkey on stats (cost=0.00..3688.21 rows=123430
width=12) -> Sort (cost=263024.32..266670.94 rows=1458648 width=4) Sort Key:
trans.stats_id -> Seq Scan on trans (cost=0.00..59706.48 rows=1458648 width=4)
I'll make a smaller test case over night..
Cheers,
Patrick