Re: The return value of allocate_recordbuf()

On Mon, Jan 5, 2015 at 1:25 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> Hmm. There is no way to check beforehand if a palloc() will fail because of
>>> OOM. We could check for MaxAllocSize, though.
>>
>> I think we need a version of palloc that returns NULL instead of
>> throwing an error. The error-throwing behavior is for the best in
>> almost every case, but I think the no-error version would find enough
>> users to be worthwhile.
> Compression is one of those areas, be it compression of WAL or another
> type. The new API would allow to fallback to the non-compression code
> path if buffer allocation for compression cannot be done because of an
> OOM.
>
> FWIW, I actually looked at how to do that a couple of weeks back, and
> you just need a wrapper function, whose content is the existing
> AllocSetAlloc, taking an additional boolean flag to trigger an ERROR
> or leave with NULL if an OOM appears. On top of that we will need a
> new method in MemoryContextMethods, let's call it alloc_safe, for its
> equivalent, the new palloc_safe.

MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
in allocate_recordbuf()?

Regards,

--
Fujii Masao