pg_malloc() versus malloc(0)

Per
http://archives.postgresql.org/pgsql-general/2012-10/msg00013.php
we have got a problem with the pg_malloc() interface functions that
were recently added to pg_dump and a lot of other frontend code.
Namely, that on platforms where malloc(0) returns NULL instead of
a pointer to a zero-size block, pg_malloc thinks it's a failure
and aborts the program.

There are basically two ways we could fix this:

1. Teach pg_malloc not to complain if result == NULL and size == 0.

2. Before the malloc call, have it replace size == 0 with size = 1.

#2 would guarantee no NULL returns from pg_malloc, which would be closer
to the behavior of palloc in the backend. On the other hand, it seems
a bit wasteful and inelegant. Any code that was capable of calling
malloc(0) before is presumably not going to be upset by a NULL return,
or we'd have seen trouble reports sooner.

Any opinions which way to go? I'm not convinced either way yet.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Namely, that on platforms where malloc(0) returns NULL instead of
> a pointer to a zero-size block, pg_malloc thinks it's a failure
> and aborts the program.

What's the use case for malloc(0) anyway?

> 1. Teach pg_malloc not to complain if result == NULL and size == 0.

What about not calling malloc at all in such places? Well I guess what
you want is for the pg_malloc() API to be able to never return NULL…

> 2. Before the malloc call, have it replace size == 0 with size = 1.

As I don't understand the need to malloc 0 byte I would think that's ok
as a way to simplify code…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On 1 October 2012 15:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 1. Teach pg_malloc not to complain if result == NULL and size == 0.

+1 to that proposal.

> 2. Before the malloc call, have it replace size == 0 with size = 1.

I don't like that proposal on purely aesthetic grounds.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Namely, that on platforms where malloc(0) returns NULL instead of
>> a pointer to a zero-size block, pg_malloc thinks it's a failure
>> and aborts the program.

> What's the use case for malloc(0) anyway?

See getAggregates() for an example. Yeah, we could add a special-case
code path for no aggregates, but it would be annoying and error-prone.

regards, tom lane

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 1 October 2012 15:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 1. Teach pg_malloc not to complain if result == NULL and size == 0.

> +1 to that proposal.

>> 2. Before the malloc call, have it replace size == 0 with size = 1.

> I don't like that proposal on purely aesthetic grounds.

As Dimitri pointed out, there's really a third alternative, which is
to force a NULL result for pg_malloc(0), ie

void *
pg_malloc(size_t size)
{
void *tmp;

+ if (size == 0)
+ return NULL;
+
tmp = malloc(size);
if (!tmp)
{
psql_error("out of memory\n");
exit(EXIT_FAILURE);
}
return tmp;
}

A key advantage of either #2 or #3 over #1 is that they eliminate the
platform-dependent behavior, ie you can test anywhere and get the same
results. #1 doesn't ensure that.

The fact that 9.2 managed to get out the door without anybody noticing
that pg_dump was basically broken on AIX (as well as any other platform
with this behavior) says to me that we need a fix that makes the
behavior not platform-specific. Given that the majority of platforms
behave more like #2, maybe that's the best solution, but I could live
with #3 as well.

regards, tom lane