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