Re: PLy_malloc and plperl mallocs

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PLy_malloc and plperl mallocs
Date: 2010-11-28 14:01:44
Message-ID: 4CF260C8.9080006@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28/11/10 05:23, Andrew Dunstan wrote:
>
>
> On 11/27/2010 10:28 PM, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=<wulczer(at)wulczer(dot)org> writes:
>>> I noticed that PL/Python uses a simple wrapper around malloc that does
>>> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
>>> normally do ERROR if we run out of memory?
>>> And while looking at how PL/Perl does these things I find that one
>>> failed malloc (in compile_plperl_function) throws an ERROR, and the rest
>>> (in plperl_spi_prepare) are simply unguarded...
>>> I guess PL/Python should stop throwing FATAL errors and PL/Perl should
>>> get its own malloc_or_ERROR helper and start using that.
>> The real question is why they're not using palloc instead.
>>
>>
>
> Well, the stuff in plperl_spi_prepare needs to be allocated in a
> long-lived context. We could use palloc in TopMemoryContext instead, I
> guess.

I'll do that for PL/Python for now. While on the topic of needless FATAL
errors, if you try to create a Python 3 function in a session that
already loaded Python 2, you get a FATAL error with an errhint of

Start a new session to use a different Python major version.

If you raise a FATAL error, you don't really have much choice than to
start a new session, since the current one just got nuked, no? Should
this be an ERROR?

Cheers,
Jan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2010-11-28 14:45:54 Re: Rethinking representation of sort/hash semantics in queries and plans
Previous Message Andrew Dunstan 2010-11-28 13:43:16 Re: PROPOSAL of xmlvalidate