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

Haiyang Li <mohen.lhy@alibaba-inc.com>

From: 李海洋(陌痕) <mohen.lhy@alibaba-inc.com>

To: "Tom Lane" <tgl@sss.pgh.pa.us>

Cc: "feichanghong" <feichanghong@qq.com>, "ocean_li_996" <ocean_li_996@163.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>

Date: 2025-09-07T08:24:05Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Eliminate duplicative hashtempcxt in nodeSubplan.c.
- bdc6cfcd12f5 19 (unreleased) landed
Fix memory leakage in nodeSubplan.c.
- e1da9c072106 16.11 landed
- bc865ff6d1f0 18.0 landed
- abdeacdb0920 19 (unreleased) landed
- 8b6c29afd125 13.23 landed
- 862980f924ff 17.7 landed
- 5eab9b0a473e 14.20 landed
- 5ac973892b09 15.15 landed
Do execGrouping.c via expression eval machinery, take two.
- bf6c614a2f2c 11.0 cited
Fix potential failure when hashing the output of a subplan that produces
- 133924e13e00 9.1.0 cited

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?
— 
Thanks
Haiyang Li