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

Tom Lane <tgl@sss.pgh.pa.us>

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

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

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-08T20:46:10Z

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

Attachments

v04-0001-Fix-memory-leakage-in-nodeSubplan.c.patch (text/x-diff) patch v4-0001
v04-0002-Eliminate-duplicative-hashtempcxt-in-nodeSubplan.patch (text/x-diff) patch v4-0002

I wrote:
> I thought about that too, but that would result in two short-lived
> contexts and two reset operations per tuple cycle where only one
> is needed.  I'm rather tempted to fix nodeSubplan.c by making it
> use innerecontext->ecxt_per_tuple_memory instead of a separate
> hash tmpcontext.  That context is getting reset already, at least in
> buildSubPlanHash().  That's probably too risky for the back branches
> but we could do it in HEAD.

Concretely, I'm thinking about the attached.  0001 is the same
logic as in the v02 patch, but I felt we could make the code
be shorter and prettier instead of longer and uglier.  That's
meant for back-patch, and then 0002 is for master only.

			regards, tom lane