回复:回复:BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset

From: 李海洋(陌痕) <mohen(dot)lhy(at)alibaba-inc(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "feichanghong" <feichanghong(at)qq(dot)com>, "ocean_li_996" <ocean_li_996(at)163(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: 回复:回复:BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset
Date: 2025-09-07 08:24:05
Message-ID: bfb8be51-18e5-4839-a555-5c3d0ccd32d0.mohen.lhy@alibaba-inc.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2025-09-06 20:31:53 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> After contemplating things for awhile, I think that feichanghong’s
> idea is the right one after all: in each of the functions that switch
> into hashtable->tempcxt, let's do a reset on the way out, as attached.
> That's straightforward and visibly related to the required data
> lifespan.
I have considered this approach as well, but my concern is that "tempcxt"
is not always an independent memory context. In some cases, it references
another context — for example, in nodeSetOp.c’s "build_hash_table", “tempcxt"
points to "setopstate->ps.ps_ExprContext->ecxt_per_tuple_memory". There is
similar usage in nodeAgg.c as well. I’m not entirely sure that this approach would
not discard data we still need, because the lifespan of
"ps_ExprContext->ecxt_per_tuple_memory" seems to be longer than “tempcxt”.
Should we make tempcxt a completely independent memory context?

Thanks
Haiyang Li

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message feichanghong 2025-09-07 09:02:23 Re: BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset
Previous Message Tom Lane 2025-09-06 20:31:53 Re: 回复:BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset