Re: PLy_malloc and plperl mallocs
От | Jan Urbański |
---|---|
Тема | Re: PLy_malloc and plperl mallocs |
Дата | |
Msg-id | 4CF260C8.9080006@wulczer.org обсуждение исходный текст |
Ответ на | Re: PLy_malloc and plperl mallocs (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: PLy_malloc and plperl mallocs
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: