Re: Large join runs out of memory in 8.1

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

--
Joe Sunday <sunday(at)csh(dot)rit(dot)edu> http://www.csh.rit.edu/~sunday/
Computer Science House, Rochester Inst. Of Technology