Re: Out of Memory errors are frustrating as heck! - Mailing list pgsql-performance

From Tom Lane
Subject Re: Out of Memory errors are frustrating as heck!
Date
Msg-id 32096.1555381683@sss.pgh.pa.us
Whole thread Raw
In response to Re: Out of Memory errors are frustrating as heck!  (Gunther <raj@gusw.net>)
Responses Re: Out of Memory errors are frustrating as heck!  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-performance
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



pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: PostgreSQL upgrade.
Next
From: Alvaro Herrera
Date:
Subject: Re: Out of Memory errors are frustrating as heck!