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