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
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. |