Horton

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

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

View thread
From: 李海洋(陌痕) <mohen.lhy@alibaba-inc.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "feichanghong" <feichanghong@qq.com>
Cc: "ocean_li_996" <ocean_li_996@163.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2025-09-05T05:13:20Z
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 →

  1. Eliminate duplicative hashtempcxt in nodeSubplan.c.

  2. Fix memory leakage in nodeSubplan.c.

  3. Do execGrouping.c via expression eval machinery, take two.

  4. Fix potential failure when hashing the output of a subplan that produces

Attachments

On 2025-09-03 23:35 Tom Lane <tgl@sss.pgh.pa.us> writes:
> I wonder why ExecInitSubPlan is making a separate context for this at all,
> rather than using some surrounding short-lived context.
This behavior was introduced by commit 133924e to fix one bug. AFAICS, the
tempcxt is only used by hashfunc evaluation. We should reset tempcxt after per 
hashtable find if tempcxt is a separate context.
> If we do keep a separate context, I agree with the idea of one
> MemoryContextReset in the exit of ExecHashSubPlan, but the proposed
> patch seems like a mess. I think what we ought to do is refactor
> ExecHashSubPlan so that there's exactly one "ExecClearTuple(slot)”
> down at the bottom, and then we can add a MemoryContextReset after it.
Based on this thought, I have implemented a new patch in attachment. 
It’s worth noting that a similar issue also exists in buildSubPlanHash. The leak
occurs while building the hash table from the subplan’s result set. If the test SQL
in [1] is modified to
```
EXPLAIN ANALYZE
 SELECT * FROM test1
 WHERE a NOT IN 
 (SELECT a FROM test1 limit 100000);
```
 (and work_mem is adjusted so that the plan uses a hashed subplan), you can
confirm it. To address this, I have also added a MemoryContextReset tempcxt
after each hash table probe in buildSubPlanHash.
Additional, the patch does not include a test case.
Looking forward to your feedback.
—
Thanks
Haiyang Li
[1] https://www.postgresql.org/message-id/19040-c9b6073ef814f48c%40postgresql.org <https://www.postgresql.org/message-id/19040-c9b6073ef814f48c%40postgresql.org >