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.61 rows=1596 width=8)
-> Hash Left Join (cost=4143.88..115550.16 rows=1633701 width=8)
Hash Cond: ("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=123430 width=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 | 586
2005-08-28 00:00:01 | 378
2005-08-28 00:20:00 | 878
...
So, no results with enable_hashjoin=on.
Broken:
QUERY PLAN
--------------------------------------------------------------------------------------
GroupAggregate (cost=326296.78..338449.98 rows=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=123430 width=12)
Working:
QUERY PLAN
---------------------------------------------------------------------------------------------------
GroupAggregate (cost=506460.77..518613.97 rows=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