PLy_malloc and plperl mallocs

Started by Jan Urbańskiabout 15 years ago5 messages
#1Jan Urbański
wulczer@wulczer.org

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jan Urbański (#1)
Re: PLy_malloc and plperl mallocs

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.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

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#2)
Re: PLy_malloc and plperl mallocs

On 11/27/2010 10:28 PM, Tom Lane wrote:

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=<wulczer@wulczer.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

#4Jan Urbański
wulczer@wulczer.org
In reply to: Andrew Dunstan (#3)
Re: PLy_malloc and plperl mallocs

On 28/11/10 05:23, Andrew Dunstan wrote:

On 11/27/2010 10:28 PM, Tom Lane wrote:

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=<wulczer@wulczer.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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jan Urbański (#4)
Re: PLy_malloc and plperl mallocs

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.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