Re: Safe memory allocation functions

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Safe memory allocation functions
Date: 2015-01-27 08:34:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2015-01-27 17:27:53 +0900, Michael Paquier wrote:
> Alvaro Herrera wrote:
> >> So how about something like
> >>
> >> #define ALLOCFLAG_HUGE 0x01
> >> #define ALLOCFLAG_NO_ERROR_ON_OOM 0x02
> >> void *
> >> MemoryContextAllocFlags(MemoryContext context, Size size, int flags);
> The flag for huge allocations may be useful, but I don't actually see
> much value in the flag ALLOC_NO_OOM if the stuff in aset.c returns
> unconditionally NULL in case of an OOM and we let palloc complain
> about an OOM when allocation returns NULL. Something I am missing
> perhaps?

I guess the idea is to have *user facing* MemoryContextAllocExtended()
that can do both huge and no-oom allocations. Otherwise we need palloc
like wrappers for all combinations.
We're certainly not just going to ignore memory allocation failures
generally in in MemoryContextAllocExtended()....


Andres Freund

Andres Freund
PostgreSQL Development, 24x7 Support, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2015-01-27 09:08:30 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Michael Paquier 2015-01-27 08:27:53 Re: Safe memory allocation functions