Re: Patch for memory leaks in index scan

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-patches by date

  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