Re: Safe memory allocation functions

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Safe memory allocation functions
Date: 2015-01-15 15:57:05
Message-ID: 20150115155705.GP1663@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:

> 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.

Your understanding seems correct to me. I was just saying that your
description of Tom's argument to dislike the idea seemed at odds with
what he was actually saying.

> 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().

I liked palloc_noerror() better myself FWIW.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-15 15:57:10 Re: s_lock.h default definitions are rather confused
Previous Message Alvaro Herrera 2015-01-15 15:53:42 Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]