| 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: | Whole Thread | Raw Message | 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 ] |