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

On Sep 7, 2025, at 16:24, 李海洋(陌痕) <mohen.lhy@alibaba-inc.com> wrote:

On 2025-09-06 20:31:53 Tom Lane <tgl@sss.pgh.pa.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?