Re: Safe memory allocation functions

On Wed, Jan 14, 2015 at 9:42 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>> On Tue, Jan 13, 2015 at 10:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > However, there is a larger practical problem with this whole concept,
>> > which is that experience should teach us to be very wary of the assumption
>> > that asking for memory the system can't give us will just lead to nice
>> > neat malloc-returns-NULL behavior. Any small perusal of the mailing list
>> > archives will remind you that very often the end result will be SIGSEGV,
>> > OOM kills, unrecoverable trap-on-write when the kernel realizes it can't
>> > honor a copy-on-write promise, yadda yadda. Agreed that it's arguable
>> > that these only occur in misconfigured systems ... but misconfiguration
>> > appears to be the default in a depressingly large fraction of systems.
>> > (This is another reason for "_safe" not being the mot juste :-()
>>
>> I don't really buy this. It's pretty incredible to think that after a
>> malloc() failure there is absolutely no hope of carrying on sanely.
>> If that were true, we wouldn't be able to ereport() out-of-memory
>> errors at any severity less than FATAL, but of course it doesn't work
>> that way. Moreover, AllocSetAlloc() contains malloc() and, if that
>> fails, calls malloc() again with a smaller value, without even
>> throwing an error.
>
> I understood Tom's point differently: instead of malloc() failing,
> malloc() will return a supposedly usable pointer, but later usage of it
> will lead to a crash of some sort. We know this does happen in reality,
> because people do report it; but we also know how to fix it. And for
> systems that have been correctly set up, the new behavior (using some
> plan B for when malloc actually fails instead of spuriously succeeding
> only to cause a later crash) will be much more convenient.

Hmm, I understood Tom to be opposing the idea of a palloc variant that
returns NULL on failure, and I understand you to be supporting it.
But maybe I'm confused. Anyway, I support it. I agree that there are
systems (or circumstances?) where malloc is going to succeed and then
the world will blow up later on anyway, but I don't think that means
that an out-of-memory error is the only sensible response to a palloc
failure; returning NULL seems like a sometimes-useful alternative.

I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail()
or palloc_null() or palloc_no_oom() or palloc_unsafe().

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company