Re: TupleTableSlot abstraction - Mailing list pgsql-hackers

From Andres Freund
Subject Re: TupleTableSlot abstraction
Date
Msg-id 20190227054238.c7epq2so7nly5yfh@alap3.anarazel.de
Whole thread Raw
In response to Re: TupleTableSlot abstraction  (Michael Paquier <michael@paquier.xyz>)
Responses Re: TupleTableSlot abstraction  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On 2019-02-27 14:21:52 +0900, Michael Paquier wrote:
> On Sat, Feb 16, 2019 at 05:07:44PM -0500, Jeff Janes wrote:
> > By blind analogy to the changes made to matview.c, I think that createas.c
> > is missing a heap_freetuple, as attached.

First, sorry to have been slow answering. I was whacking around code
further modifying this, and thought I'd just solve the immediate issue
here by committing the followup work that removes getting the tuple out
of the slot entirely. That took longer than planned, so it makes sense
to commit an interim fix.


> I think that you are right.  CTAS and materialized views share a lot
> when it comes to relation creation and initial table loading.  I have
> reproduced the leak and could notice that your fix is correct.  So
> committed.

I'm not so sure that's the architecturally correct fix however. Is it
actually guaranteed, given expanded tuples, toasting, etc, that there's
no other memory leak here? I wonder if we shouldn't work twoards using a
short lived memory context here. Note how e.g. printtup() uses a short
lived context for its work.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: pgsql: Avoid creation of the free space map for small heaprelations, t
Next
From: Markus Winand
Date:
Subject: Re: Index INCLUDE vs. Bitmap Index Scan