Gunther <raj@gusw.net> writes:
> Tom (BTW, your mail server rejects my direct mail,
[ raised eyebrow ] It's coming through fine AFAICS.
>> I'm pretty sure that's not the droid we're looking for.
>> ExecHashJoinGetSavedTuple does palloc a new tuple, but it immediately
>> sticks it into a TupleTableSlot that will be responsible for freeing
>> it (when the next tuple is stuck into the same slot).
> I did continue a "few times", but few as in a dozen, it's always the same
Well, I still don't believe that ExecHashJoinGetSavedTuple is the issue.
It has a mechanism for freeing the allocation at the right time, and
if that were broken then all hash joins would be leaking. It's easy
to prove that that's not so, both by experiment and by the lack of
other reports.
It's barely conceivable that in your particular query, there's something
acting to break that which doesn't manifest typically; but I think it's
much more likely that you simply haven't found the culprit allocation.
It's quite feasible that many many ExecHashJoinGetSavedTuple calls would
go by in between problem allocations.
Another line of thought is that maybe the problem is with realloc'ing
something larger and larger? You could try trapping AllocSetRealloc
to see.
(BTW, it looks like we *do* have a leak with simple hash joins in
HEAD. But not v11.)
regards, tom lane