Re: Endless loop calling PL/Python set returning functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexey Grishchenko <agrishchenko(at)pivotal(dot)io>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Endless loop calling PL/Python set returning functions
Date: 2016-03-10 16:33:13
Message-ID: 4805.1457627593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexey Grishchenko <agrishchenko(at)pivotal(dot)io> writes:
> One scenario when the problem occurs, is when you are calling the same
> set-returning function in a single query twice. This way they share the
> same "globals" which is not a bad thing, but when one function finishes
> execution and deallocates input parameter's global, the second will fail
> trying to do the same. I included the fix for this problem in my patch

> The second scenario when the problem occurs is when you want to call the
> same PL/Python function in recursion. For example, this code will not work:

Right, the recursion case is what's not being covered by this patch.
I would rather have a single patch that deals with both of those cases,
perhaps by *not* sharing the same dictionary across calls. I think
what you've done here is not so much a fix as a band-aid. In fact,
it doesn't even really fix the problem for the two-calls-per-query
case does it? It'll work if the first execution of the SRF is run to
completion before starting the second one, but not if the two executions
are interleaved. I believe you can test that type of scenario with
something like

select set_returning_function_1(...), set_returning_function_2(...);

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2016-03-10 16:33:49 Re: Add generate_series(date,date) and generate_series(date,date,integer)
Previous Message Michael Paquier 2016-03-10 16:30:51 Re: Add generate_series(date,date) and generate_series(date,date,integer)