Thread: 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@sss.pgh.pa.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@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. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.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@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