On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
> <hlinnakangas@vmware.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.
--
Michael