"Han Holl" <han.holl@prismant.nl> writes:
>> No, not to me anyway. I would not be surprised if there's some leak in
>> the SQL-function code, but could I trouble you for a complete example,
>> rather than having to reverse-engineer one?
> Of course. I hope you have a Linux like system, otherwise the following
> might not run.
Okay, it turns out this is indeed an aspect of a known problem, namely
that SQL-language functions aren't good about cleaning up query-lifespan
data created by the queries they run. The individual queries really
ought to be run using a query memory context that's shorter-lived than
that of the query that's calling the function. But they're not, yet.
I was able to eliminate the memory leak in your example by adding
"pfree(scanstate);" to the end of ExecEndSeqScan(). However, that's
not a general solution, since there are comparable leaks in most of
the other executor node types; and even if we eliminated them all today,
it would be difficult to prevent new ones from appearing in future.
The right long-term solution is to arrange for all query-lifetime data
to be allocated in a specific context that can be freed in-toto when
we end the query. To do this cleanly, we have to fix the executor to
not scribble on plan trees (executor state nodes should point to plan
nodes, never vice-versa). I've been intending to do that for awhile,
but it's not done yet ...
regards, tom lane
