I wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> Attached is a patch adding the following set of functions for frontend
>> and backends returning NULL instead of reporting ERROR when allocation
>> fails:
>> - palloc_safe
>> - palloc0_safe
>> - repalloc_safe
> Unimpressed with this naming convention. "_unsafe" would be nearer
> the mark ;-)
Less snarkily: "_noerror" would probably fit better with existing
precedents in our code.
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 :-()
In that light, I'm not really convinced that there's a safe use-case
for a behavior like this. I certainly wouldn't risk asking for a couple
of gigabytes on the theory that I could just ask for less if it fails.
regards, tom lane
