Re: The return value of allocate_recordbuf() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: The return value of allocate_recordbuf()
Date
Msg-id CAB7nPqTcTHhOdkxtjPf3OTFCHZqnAbG8Q1qLPQ5yO=txg1YyyQ@mail.gmail.com
Whole thread Raw
In response to Re: The return value of allocate_recordbuf()  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers


On Thu, Apr 2, 2015 at 9:10 AM, Bruce Momjian <bruce@momjian.us> wrote:
Where are we on this?

If we want to have allocate_recordbuf error out properly on frontend side, we are going to need a equivalent of MemoryContextAllocExtended for frontends in the shape of palloc_extended able to take control flags. That's what the patch I sent previously proposes. And this is 9.5 material, except if we accept that allocate_recordbuf() will fail all the time in case of an OOM (the only code path where we don't need to mandatory fail with OOM for this routine is used only with WAL_DEBUG in xlog.c). Now if we push forward with this patch, and I think we should to maintain compatibility with WAL_DEBUG with previous versions, we'll need to add as well an ERROR when an OOM occurs after XLogReaderAllocate in logical.c, and in pg_rewind's parsexlog.c.
--
Michael

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: The return value of allocate_recordbuf()
Next
From: Jim Nasby
Date:
Subject: Re: Relation extension scalability