Re: BUG #16112: large, unexpected memory consumption

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, ben(at)lantern(dot)is, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16112: large, unexpected memory consumption
Date: 2019-11-13 17:47:33
Message-ID: 20191113174733.zwfukrx7atfh65t3@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019-11-13 12:21:47 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2019-11-13 15:50:04 +0100, Tomas Vondra wrote:
> >> The attached trivial patch fixes that by adding a pfree() at the end of
> >> the function.
>
> > Hm. That's clearly an improvement. But I'm not quite sure it's really
> > the right direction. It seems like a bad idea to rely on
> > ExecMakeTableFunctionResult() otherwise never leaking any memory.
>
> Considering that ExecMakeTableFunctionResult went from zero pallocs
> to one, I don't see a strong reason why it should have bothered with
> a private memory context before, nor do I think that's a good
> response now.

Well, that relies on type_is_rowtype(), exprType(),
TupleDescInitEntry(), lookup_rowtype_tupdesc_copy() not to leak memory
(besides lookup_rowtype_tupdesc_copy()'s return type, which is
explicitly freed). Which is true, but still seems not super reliable.

Thinking about it for a second longer, I don't think we'd need a new
context - afaict argcontext has exactly the lifetime requirements
needed.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ranier Vilela 2019-11-13 17:55:40 RE: [BUG] Uninitializaed configOut.leafType used.
Previous Message Andres Freund 2019-11-13 17:29:46 Re: [BUG] Uninitialized var buffer flag used.