>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "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.
The tables and views aren't that hard; finding a way to generate
enough fake data may be a challenge. (I assume that since it took
over a half hour to run out of memory, the volume of data needs to be
sufficient to get there.)
> Is this a 32-bit or 64-bit build?
32-bit PostgreSQL on 32-bit Linux.
> Also, does the leak still occur if
> you just run the query as-is rather than EXPLAIN ANALYZE it?
I will find out.
-Kevin