Re: Out of memory error in 8.1.0 Win32

From: "Relyea, Mike" <Mike(dot)Relyea(at)xerox(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Out of memory error in 8.1.0 Win32
Date: 2006-06-19 12:46:53
Message-ID: 1806D1F73FCB7F439F2C842EE0627B18041908A5@usa0300ms01.na.xerox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

work_mem = 262144

I'm still trying to figure out how to track the memory usage in
ExecutorState

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org
[mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Sunday, June 18, 2006 11:13 PM
To: Qingqing Zhou
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Out of memory error in 8.1.0 Win32

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
>> ExecutorState: 550339936 total in 123 blocks; 195005920 free (740144
>> chunks); 355334016 used
>> ...
>> HashBatchContext: 293593176 total in 44 blocks; 3107384 free (80
chunks);
>> 290485792 used

> Er, looks like a huge hash-join but not sure if it is a memory leak,
Tom?

A hash join could suck a lot of memory in HashBatchContext, but what
seems wrong about your report is all that memory in ExecutorState.
Please see if you can track where that went.

BTW, what was work_mem set to in this example? In theory the
HashBatchContext shouldn't get much bigger than work_mem.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Clodoaldo Pinto 2006-06-19 13:11:11 How to build with bigger WAL segment file?
Previous Message Wes 2006-06-19 12:44:23 Re: Adding foreign key constraints without integrity