On Tuesday, October 02, 2012 06:30:33 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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
