On 2025-09-09 03:05:09 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> feichanghong <feichanghong(at)qq(dot)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