Re: Patch for memory leaks in index scan - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: Patch for memory leaks in index scan
Date
Msg-id 200206210045.g5L0jWP14185@candle.pha.pa.us
Whole thread Raw
In response to Patch for memory leaks in index scan  (Dmitry Tkach <dmitry@openratings.com>)
List pgsql-bugs
Your patch has been added to the PostgreSQL unapplied patches list at:

    http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Dmitry Tkach wrote:
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_dumpall should permit quiet operation
Next
From: Peter Mount
Date:
Subject: Re: Bug #694: can't store {digits} using JDBC