Re: pg_malloc() versus malloc(0) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_malloc() versus malloc(0)
Date
Msg-id 24519.1349103635@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_malloc() versus malloc(0)  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 1 October 2012 15:00, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: CTE optimization fence on the todo list?
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown