From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unchecked malloc |
Date: | 2005-09-27 05:03:25 |
Message-ID: | 7684.1127797405@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> There are several places in both backend and tools that forget to check the
> return value of malloc(). For example(8.0.1),
> backend/port/dynloader/beos.c/pg_dlopen()
Dead port, probably not worth fixing.
> backend/bootstrap/bootstrap.c/AddStr()
This code will never be run under memory pressure, so although
it theoretically should be fixed, I'm having a hard time getting
excited about it. In any case palloc would be the correct fix.
> port/strdup.c/strdup()
Definitely broken; I just fixed it to conform to the SUS
http://www.opengroup.org/onlinepubs/007908799/xsh/strdup.html
(of course, this code isn't used on any remotely modern
platform, so it's probably not very relevant...)
> bin/pg_dump/common.c/findParentsByOid()
Probably should be fixed, although if pg_dump runs out of memory
it's just gonna fail anyway.
> To report the "out of memory" error, we should differenciate if
> ErrorContext is already set up.
No, because you're thinking in terms of the backend environment, and
generally in the backend the answer to "when to use malloc directly"
is "never". The client-side tools are the only place where this is
a serious question, and offhand I'd say "gripe to stderr and exit(1)"
is going to be the right answer in all cases there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Peacetree | 2005-09-27 05:09:19 | Re: [PERFORM] A Better External Sort? |
Previous Message | Joshua D. Drake | 2005-09-27 04:54:46 | Re: State of support for back PG branches |