<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Apr 2, 2015 at 9:10 AM, Bruce
Momjian<span dir="ltr"><<a href="mailto:bruce@momjian.us" target="_blank">bruce@momjian.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><spanclass=""> </span>Where are we on this?<span class=""><font color="#888888"><br
/></font></span></blockquote></div><br/></div><div class="gmail_extra">If we want to have <span
class="im"><span>allocate_recordbuferror out properly on frontend side, we are going to need a equivalent of
MemoryContextAllocExtendedfor frontends in the shape of palloc_extended able to take control flags. That's what the
patchI sent previously proposes. And this is 9.5 material</span></span>, except if we accept that allocate_recordbuf()
willfail all the time in case of an OOM (the only code path where we don't need to mandatory fail with OOM for this
routineis used only with WAL_DEBUG in xlog.c). Now if we push forward with this patch, and I think we should to
maintaincompatibility with WAL_DEBUG with previous versions, we'll need to add as well an ERROR when an OOM occurs
afterXLogReaderAllocate in logical.c, and in pg_rewind's parsexlog.c.<br />-- <br /><div
class="gmail_signature">Michael<br/></div></div></div>