Re: TupleTableSlot abstraction

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: TupleTableSlot abstraction
Дата
Msg-id 20190227054238.c7epq2so7nly5yfh@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: TupleTableSlot abstraction  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: TupleTableSlot abstraction  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: pgsql: Avoid creation of the free space map for small heaprelations, t
Следующее
От: Markus Winand
Дата:
Сообщение: Re: Index INCLUDE vs. Bitmap Index Scan