Skip site navigation (1) Skip section navigation (2)

Re: PLy_malloc and plperl mallocs

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PLy_malloc and plperl mallocs
Date: 2010-11-28 04:23:02
Message-ID: 4CF1D926.70405@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-28 04:59:04
Subject: Re: [COMMITTERS] pgsql: Remove outdated comments from the regression test files.
Previous:From: Bruce MomjianDate: 2010-11-28 04:18:58
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group