Skip site navigation (1) Skip section navigation (2)

Patch for memory leaks in index scan

From: Dmitry Tkach <dmitry(at)openratings(dot)com>
To: pgsql-bugs(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Patch for memory leaks in index scan
Date: 2002-04-19 17:31:43
Message-ID: 3CC0547F.2090300@openratings.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
Ok, this sit around for a while, and, because there was no responses, I assume, that nothing jumps out
at you as being terribly with my logic...
Here is the patch (see the original problem description in the bottom)... It seems to be working (at least that query,
that used to be running out of memory is now able to finish).

*** nodeIndexscan.c.orig        Fri Apr 19 10:29:57 2002
--- nodeIndexscan.c     Fri Apr 19 10:30:00 2002
***************
*** 505,510 ****
--- 505,514 ----
          */
         ExecClearTuple(scanstate->cstate.cs_ResultTupleSlot);
         ExecClearTuple(scanstate->css_ScanTupleSlot);
+       pfree(scanstate);
+       pfree(indexstate->iss_RelationDescs);
+       pfree(indexstate->iss_ScanDescs);
+       pfree(indexstate);
   }

   /* ----------------------------------------------------------------

I hope, it helps....

Dima


-------- Original Message --------

It seems that ExecInit/EndIndexScan is leaking some memory...

For example, if I run a query, that uses an index scan, and call MemoryContextStats (CurrentMemoryContext) before
ExecutorStart() and after ExecutorEnd() in ProcessQuery(), I am consistently seeing that the 'after' call shows
256 bytes more used, then 'before'...

In many common cases, this is not a problem, because pg_exec_query_string () will call
MemoryContextResetAndDeleteChildren(), that will clean everything up eventually...

But it still seems to cause problems, when the index scan is not directly invoked from pg_exec_query_string ().
For example:

create table a
(
     id int primary key,
     data char(100)
);

create table b
(
     id int references a,
     more_data char(100)
);

create function merge_data (int,data) returns char(200) as 'select data || $2 from a where id = $1;' language 'sql';

Now, if b is large enough, then something like:

select merge_data (id,more_data) from b;

Will eventually run out of memory - it will loose 256 bytes after each row, or about a GIG after 4 million rows...

The problem seems to be in ExecEndIndexScan - it does not release scanstate, indexstate, indexstate->iss_RelationDescs
and indexstate -> iss_ScanDescs...

I am not familiar enough with the core code, to just jump in and start fixing it, but I can make the patch,
test it and send it to you, if you guys let me know if what I am saying makes sense to you...
Or am I missing something here?

Thanks!

Dima



Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-04-19 17:54:03
Subject: Re: Patch for memory leaks in index scan
Previous:From: Alban M├ędiciDate: 2002-04-19 16:08:59
Subject: Still Inheritance Bugs with postgres 7.2.1

pgsql-patches by date

Next:From: Tom LaneDate: 2002-04-19 17:54:03
Subject: Re: Patch for memory leaks in index scan
Previous:From: Joe ConwayDate: 2002-04-19 17:25:56
Subject: Re: Odd(?) RI-trigger behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group