Re: pl/python do not delete function arguments

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/python do not delete function arguments
Date: 2011-02-14 21:22:49
Message-ID: 4D599D29.20903@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14/02/11 22:13, Jan Urbański wrote:
> On 14/02/11 21:06, Peter Eisentraut wrote:
>> On ons, 2011-02-09 at 10:02 +0100, Jan Urbański wrote:
>>> On 09/02/11 04:52, Hitoshi Harada wrote:
>>>> 2010/12/31 Jan Urbański <wulczer(at)wulczer(dot)org>:
>>>>> (continuing the flurry of patches)
>>>>>
>>>>> Here's a patch that stops PL/Python from removing the function's
>>>>> arguments from its globals dict after calling it. It's
>>>>> an incremental patch on top of the plpython-refactor patch sent in
>>>>> http://archives.postgresql.org/message-id/4D135170.3080705@wulczer.org.
>>>>>
>>>>> Git branch for this patch:
>>>>> https://github.com/wulczer/postgres/tree/dont-remove-arguments
>>>>>
>>>>> Apart from being useless, as the whole dict is unreffed and thus freed
>>>>> in PLy_procedure_delete, removing args actively breaks things for
>>>>> recursive invocation of the same function. The recursive callee after
>>>>> returning will remove the args from globals, and subsequent access to
>>>>> the arguments in the caller will cause a NameError (see new regression
>>>>> test in patch).
>>>>
>>>> I've reviewed this. The patch is old enough to be rejected by patch
>>>> command, but I manged to apply it by hand.
>>>> It compiles clean. Added tests pass.
>>>> I created fibonacci function similar to recursion_test in the patch
>>>> and confirmed the recursion raises error on 9.0 but not on 9.1.
>>>> Doc is not with the patch since this change is to remove unnecessary
>>>> optimization internally.
>>>>
>>>> "Ready for Committer"
>>>
>>> Thanks,
>>>
>>> patch merged with HEAD attached.
>>
>> Curiously, without the patch the recursion_test(4) call fails but
>> recursion_test(5) passes. Anyone know why?

Baah, damn, did not read the "without patch" part.

The problem is that every *second* call to the function fails,
regardless of the number. The first execution succeeds, but then
PLy_delete_args deletes the argument from the globals, and when the next
execution tries to fetch "n" from it, it raises a KeyError.

Jan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-02-14 22:02:15 Re: Scheduled maintenance affecting gitmaster
Previous Message Tom Lane 2011-02-14 21:21:39 Re: sepgsql contrib module