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

Re: xmalloc => pg_malloc

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: xmalloc => pg_malloc
Date: 2012-10-02 16:52:38
Message-ID: 201210021852.38739.andres@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tuesday, October 02, 2012 06:30:33 PM Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> >> pg_calloc	(randomly different API for pg_malloc0)
> > 
> > Do we need this?
> 
> I thought about getting rid of it, but there are some dozens of calls
> scattered across several files, so I wasn't sure it was worth it.
I always found calloc to be a pointless API but by now I have learned what it 
means so I don't have a strong opinion.


> > I wonder whether the same set of functions should also be available in
> > the backend with ereport(EC_OUT_OF_MEMORY, ...) behaviour as well.
> 
> In the backend, you almost always ought to be using palloc instead.
> The only places where it's really appropriate to be using malloc
> directly are where you don't want an error thrown for out-of-memory.
> So I think providing these in the backend would do little except to
> encourage bad programming.
We seem to have 100+ usages of malloc() anyway. Several of those are in helper 
libraries like regex/* though. A quick grep shows most of the others to be 
valid in my opinion. Mostly its allocating memory which is never deallocated 
but to big to unconditionally allocated.

The quick grep showed that at least src/backend/utils/misc/ps_status.c doesn't 
properly check the return value. Others (mctx.c) use Asserts...

Andres
-- 
Andres Freund		http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


In response to

pgsql-hackers by date

Next:From: Stephen FrostDate: 2012-10-02 16:58:15
Subject: Re: Hash id in pg_stat_statements
Previous:From: Phil SorberDate: 2012-10-02 16:44:26
Subject: Re: xmalloc => pg_malloc

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