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-09T07:30:48Z
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

On 2025-09-09 03:05:09 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> feichanghong <feichanghong@qq.com> writes:
> > For v04-0002, I checked the commit history, and before commit 133924e1,
> > buildSubPlanHash was using ecxt_per_tuple_memory. It seems that the
> > "Subplan HashTable Temp Context" was introduced in order to fix a certain bug.
> 
> It was a different ExprContext's ecxt_per_tuple_memory, though.
> This one is owned locally by the TupleHashTable.
I checked buildSubPlanHash in nodeSubplan.c before commit 133924e1. AFAICS, the tempcxts
are both referenced innerecontext->ecxt_per_tuple_memory in v04-0002 and before commit
133924e1. They are same. 
However, the changed behavior of TupleHashTableMatch introduced by commit
bf6c614a (noted in [1]) may make the condition：
```
However, the hashtable routines feel free to reset their temp context at any time, 
which'd lead to destroying input data that was still needed.
```
no longer holds true. Then,  the lifespan of tempcxt in buildHashtable is similar
to that of innercontext->ecxt_per_tuple_memory, so it makes sense to merge the two,
I think.
BTW, I ran the test case supported in commit 133924e1 on version not contained commit
133924e1 (tag REL8_0_26). I did not find any problems. But i can not find more information
about this issue. 
Just to be safe, I think we should verify this issue.
[1] https://www.postgresql.org/message-id/160523.1757190713%40sss.pgh.pa.us <https://www.postgresql.org/message-id/160523.1757190713%40sss.pgh.pa.us >
— 
Thanks 
Haiyang Li