Re: possible memory leak with SRFs

From: Joe Conway <mail(at)joeconway(dot)com>
To: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: possible memory leak with SRFs
Date: 2010-05-08 15:17:40
Message-ID: 4BE58094.9060707@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/07/2010 09:06 PM, Nikhil Sontakke wrote:
>>> Yeah this is my basic confusion. But wouldn't the arguments be
>>> evaluated afresh on the subsequent call for this SRF?
>>
>> No, see ExecMakeFunctionResult(). If we did that we'd have serious
>> problems with volatile functions, ie srf(random()).
>
> Ok thanks. So if someone uses a really long-running srf with argument
> expression evaluations thrown in, then running into "out of memory"
> issues should be expected and then in those cases they are better off
> using multiple srf calls to get the same effect if they can..

I've very recently looked into this exact case myself for someone, and
came to the conclusion that there is no simple fix for this. If you want
to see a concrete example of a query that fails, apply your patch and
then run the regression tests -- the "misc" test will fail.

I think this is an example of why we still need to implement a real
SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
ValuePerCall sort of works from the targetlist, but it is pretty much
useless for the use cases where people really want to use it.

Or would a FROM clause ValuePerCall suffer the same issue?

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-08 16:12:16 Re: possible memory leak with SRFs
Previous Message Tom Lane 2010-05-08 14:01:06 Re: possible memory leak with SRFs