On Fri, Nov 16, 2018 at 7:46 PM Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2018-11-13 15:30:21 -0800, Andres Freund wrote: > > What I'm now planning to do is to go through the big comment in > > tuptable.h and update that to the new world. While I'm not convinced > > that that that's the best place for it, it needs to be accurate. > > > > Furthermore: > > - More comment polishing > > - I'll probably split the commits up a bit further (particulary JIT > > ignoring virtual tuple slots, inlining the hot path of > > slot_getsomeattrs()) > > - serious commit message polishing > > I've done all of that now, and pushed it. Thanks Ashutosh, Amit > Khandekar and everyone else. > Hi Andres and all, This commit 763f2edd92095b1ca2 "Rejigger materializing and fetching a HeapTuple from a slot" introduces a memory leak into the ExecutorState context which is invoked by this statement: CREATE TABLE tbloom AS SELECT (random() * 1000000)::int as i1, (random() * 1000000)::int as i2, (random() * 1000000)::int as i3, (random() * 1000000)::int as i4, (random() * 1000000)::int as i5, (random() * 1000000)::int as i6 FROM generate_series(1,50000000); By blind analogy to the changes made to matview.c, I think that createas.c is missing a heap_freetuple, as attached. It fixes the leak, and still passes "make check". Cheers, Jeff
createas_leak_fix.patch
Description: Binary data