On Fri, Nov 16, 2018 at 7:46 PM Andres Freund <andres@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.