From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Patch for memory leaks in index scan |
Date: | 2002-04-19 17:54:03 |
Message-ID: | 1801.1019238843@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> *** 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 do not believe this patch will fix anything.
In general, the EndNode routines do not bother with releasing memory,
because it's the end of the query and we're about to drop or reset
the per-query context anyway. If the above pfrees are actually needed
then there are a heck of a lot of other places that need explicit
pfrees. And that is not a path to a solution, because there will
*always* be places that forgot a pfree. What's needed is a structural
solution.
I think your real complaint is that SQL functions leak memory. They
should be creating a sub-context for their queries that can be freed
when the function finishes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-19 19:37:59 | Re: Patch for memory leaks in index scan |
Previous Message | Dmitry Tkach | 2002-04-19 17:31:43 | Patch for memory leaks in index scan |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-19 19:37:59 | Re: Patch for memory leaks in index scan |
Previous Message | Dmitry Tkach | 2002-04-19 17:31:43 | Patch for memory leaks in index scan |