On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I'm thinking we should change this to look more like the
>> MemoryContextAlloc interface. Let's have DSA_ALLOC_HUGE,
>> DSA_ALLOC_NO_OOM, and DSA_ALLOC_ZERO, just like the corresponding
>> MCXT_* flags, and a function dsa_allocate_extended() that takes a
>> flags argument. Then, dsa_allocate(x,y) can be a macro for
>> dsa_allocate_extended(x,y,0) and dsa_allocate0(x,y) can be a macro for
>> dsa_allocate_extended(x,y,DSA_ALLOC_ZERO). What this goof on my (and
>> Dilip's) part illustrates to me is that having this interface behave
>> significantly differently from the MemoryContextAlloc interface is
>> going to cause mistakes.
>
> +1
Maybe something like the attached? I didn't add DSA_ALLOC_HUGE
because there is currently no limit on allocation size (other than the
limit on total size which you can set with dsa_set_size_limit, but
that causes allocation failure, not a separate kind of error). Should
there be a per-allocation size sanity check of 1GB like palloc?
--
Thomas Munro
http://www.enterprisedb.com