Skip site navigation (1) Skip section navigation (2)

Re: Large join runs out of memory in 8.1

From: Joe Sunday <sunday(at)csh(dot)rit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Large join runs out of memory in 8.1
Date: 2006-03-15 21:35:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:

> Joe Sunday <sunday(at)csh(dot)rit(dot)edu> writes:
> > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote:
> >> What I'd try is first letting the problem case run for a bit, then
> >> stopping it with gdb and dumping out a few Kb of the frontmost memory
> >> block in the ExecutorState context.  Sometimes, looking at the data
> > Can you point me a little more in that direction? I can't figure out how
> > to get a handle to that context.
> Well, it's nearly hopeless with a non-debug build, which is what you
> seem to have there :-(.  With debug symbols, printing the parameter
> passed to AllocSetAlloc is easy enough.

Sorry, stupid moment there.

#0  AllocSetAlloc (context=0x10360918, size=160) at aset.c:510
#1  0x1021bb78 in MemoryContextAllocZero (context=0x10360918, size=160)
    at mcxt.c:529
#2  0x100324dc in heap_form_tuple (tupleDescriptor=0x1036fc80, 
    values=0x10370088, isnull=0x103700b0 "") at heaptuple.c:727
#3  0x100f586c in ExecCopySlotTuple (slot=0x1021aaa8) at execTuples.c:558
#4  0x100ee6dc in ExecutorRun (queryDesc=0x10365858, direction=272041248, 
    count=0) at execMain.c:1349
#5  0x101851f8 in ProcessQuery (parsetree=0x1036be38, plan=0x10364db0, 
    params=0x0, dest=0x102d0000, completionTag=0xffffcc00 "") at pquery.c:174
#6  0x101858ac in PortalRun (portal=0x103676c0, count=2147483647, 
    dest=0x10363ef0, altdest=0x10363ef0, completionTag=0xffffcc00 "")
    at pquery.c:1069
#7  0x101808a8 in exec_simple_query (
    query_string=0x10359208 "SELECT a.key_a, a.key_b, \n  a.column1, a.column2, a.column3,\n  b.local_a, b.local_b\nINTO TEMP x\nFROM a a, b b \nWHERE a.key_a = b.key_a \n  AND a.key_b = b.key_b\n  AND b.local_a is not null;")
    at postgres.c:1002

(gdb) print {AllocSetContext}0x10360918
$11 = {header = {type = T_AllocSetContext, methods = 0x102cd198, 
    parent = 0x10360890, firstchild = 0x103611b8, nextchild = 0x0, 
    name = 0x10360970 "ExecutorState"}, blocks = 0x960fb008, freelist = {0x0, 
    0x10370d50, 0x103702e8, 0x103702a0, 0x10373578, 0x10370518, 0x10370730, 
    0x10370938, 0x0, 0x0, 0x103714b0}, isReset = 0 '\0', initBlockSize = 8192, 
  maxBlockSize = 8388608, keeper = 0x103656a0}

The first block isn't anything I recognize:
0x960fb008:     0x10360918      0x96ec7c18      0x96101528      0x968fb008
0x960fb018:     0x10360918      0x00000008      0x00002000      0x00000000
0x960fb028:     0x10360918      0x00000008      0x0003fc03      0x00000000
0x960fb038:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb048:     0x10360918      0x00000008      0x0003fc04      0x00000000
0x960fb058:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb068:     0x10360918      0x00000008      0x0003fc05      0x00000000
0x960fb078:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb088:     0x10360918      0x00000008      0x0003fc06      0x00000000
0x960fb098:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb0a8:     0x10360918      0x00000008      0x0003fc07      0x00000000
0x960fb0b8:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb0c8:     0x10360918      0x00000008      0x0003fc08      0x00000000
0x960fb0d8:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb0e8:     0x10360918      0x00000008      0x0003fc09      0x00000000
0x960fb0f8:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb108:     0x10360918      0x00000008      0x0003fc0a      0x00000000
0x960fb118:     0x10360918      0x00000008      0x00002000      0x00000000
0x960fb128:     0x10360918      0x00000008      0x0003fc0b      0x00000000
0x960fb138:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb148:     0x10360918      0x00000008      0x0003fc0c      0x00000000
0x960fb158:     0x10360918      0x00000008      0x00000000      0x00000000
0x960fb168:     0x10360918      0x00000008      0x0003fc0d      0x00000000
(and so on)

The next block looks like the contents of table a.

I'm still working a minimal test case that exhibits the same problem.


Joe Sunday <sunday(at)csh(dot)rit(dot)edu>
Computer Science House, Rochester Inst. Of Technology

In response to

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2006-03-15 23:26:21
Subject: Re: BUG #2314: The Order changed?
Previous:From: Mattias KregertDate: 2006-03-15 18:13:39
Subject: BUG #2319: psql utf8/latin1 client_encoding bug when using '-c'

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group