Re: Large join runs out of memory in 8.1

Поиск
Список
Период
Сортировка
От Joe Sunday
Тема Re: Large join runs out of memory in 8.1
Дата
Msg-id 20060315213557.GA1167@csh.rit.edu
обсуждение исходный текст
Ответ на Re: Large join runs out of memory in 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:

> Joe Sunday <sunday@csh.rit.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\nINTOTEMP 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@csh.rit.edu>  http://www.csh.rit.edu/~sunday/
Computer Science House, Rochester Inst. Of Technology

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Large join runs out of memory in 8.1
Следующее
От: "inner"
Дата:
Сообщение: BUG #2312: Software caused connection abort (0x00002745/10053) with long Bytea (>4.5mb) in the query