Thread: 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
Jan Urbański <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
On 11/27/2010 10:28 PM, Tom Lane wrote: > Jan Urbański<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
On 28/11/10 05:23, Andrew Dunstan wrote: > > > On 11/27/2010 10:28 PM, Tom Lane wrote: >> Jan Urbański<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
Jan Urbański <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