回复：BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset
| От | 李海洋(陌痕) |
|---|---|
| Тема | 回复：BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset |
| Дата | |
| Msg-id | c765ad39-39eb-4a39-8e67-91bcb9ee65e0.mohen.lhy@alibaba-inc.com обсуждение исходный текст |
| Ответ на | Re: BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: 回复：BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset
|
| Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: