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 [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
