On 27.04.2011 04:19, Heikki Linnakangas wrote:
On 26.04.2011 21:30, Tom Lane wrote:
Heikki Linnakangas writes:
The trivial fix is to reset the per-tuple memory context between
iterations.
Have you tested this with SRFs?
ForeignNext seems like quite the wrong place for resetting
exprcontext i
On 26.04.2011 21:30, Tom Lane wrote:
Heikki Linnakangas writes:
The trivial fix is to reset the per-tuple memory context between
iterations.
Have you tested this with SRFs?
ForeignNext seems like quite the wrong place for resetting
exprcontext in any case ...
ExecScan would be more appropr
On Tue, Apr 26, 2011 at 7:15 PM, Alvaro Herrera
wrote:
> Excerpts from Heikki Linnakangas's message of mar abr 26 15:06:51 -0300 2011:
>
>> I tried to look around for other executor nodes that might
>> have the same problem. I didn't see any obvious leaks, although index
>> scan node seems to call
Heikki Linnakangas writes:
> The trivial fix is to reset the per-tuple memory context between
> iterations.
Have you tested this with SRFs?
ForeignNext seems like quite the wrong place for resetting
exprcontext in any case ...
regards, tom lane
--
Sent via pgsql-hacke
Excerpts from Heikki Linnakangas's message of mar abr 26 15:06:51 -0300 2011:
> I tried to look around for other executor nodes that might
> have the same problem. I didn't see any obvious leaks, although index
> scan node seems to call AM's getnext without resetting the memory
> context in bet
Foreign data wrapper's IterateForeignScan() function is supposed to be
called in a short-lived memory context, but the memory context is
actually not reset during query execution. That's a pretty bad memory
leak. I've been testing this with file_fdw and a large file, and "SELECT
COUNT(*) FROM f
