Re: PLy_malloc and plperl mallocs

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.

Cheers,
Jan

=?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.

regards, tom lane

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.

cheers

andrew

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

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> writes:
> 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?

I believe we decided that it had to be FATAL because the session could
no longer be trusted to execute functions of the other python version
either. Check the archives from when that patch was put in.

regards, tom lane