From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Kevin Grittner" <Kgrittn(dot)CCAP(dot)Courts(at)wicourts(dot)gov> |
Subject: | Re: 8.4devel out of memory |
Date: | 2008-09-05 17:02:17 |
Message-ID: | 26884.1220634137@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8 chunks); 1615136 used
> ExecutorState: 2787288448 total in 364 blocks; 328 free (5 chunks); 2787288120 used
Ouch. We have created a memory leak someplace, but it's hard to tell
where from this info. Can you boil this down into a self-contained test
case? I doubt it depends at all on the specific data, so the table &
view definitions plus some dummy data would probably be enough to
reproduce it.
Is this a 32-bit or 64-bit build? Also, does the leak still occur if
you just run the query as-is rather than EXPLAIN ANALYZE it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2008-09-05 17:02:54 | Re: [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker) |
Previous Message | Alvaro Herrera | 2008-09-05 16:52:05 | Re: plpgsql is not translate-aware |