| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Gunther <raj(at)gusw(dot)net> | 
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org, Justin Pryzby <pryzby(at)telsasoft(dot)com> | 
| Subject: | Re: Out of Memory errors are frustrating as heck! | 
| Date: | 2019-04-15 17:32:51 | 
| Message-ID: | 17880.1555349571@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Gunther <raj(at)gusw(dot)net> writes:
> Now I give you a bt so we have something to look at:
> #0  AllocSetAlloc (context=0x1168230, size=385) at aset.c:715
> #1  0x000000000084e6cd in palloc (size=385) at mcxt.c:938
> #2  0x000000000061019c in ExecHashJoinGetSavedTuple (file=file(at)entry=0x8bbc528, hashvalue=hashvalue(at)entry=0x7fff2e4ca76c,
>      tupleSlot=0x10856b8, hjstate=0x11688e0) at nodeHashjoin.c:1277
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'd suggest
continuing a few times and looking for other code paths leading
to AllocSetAlloc in this context.
My first thought on noticing the SELECT DISTINCT was that you might be
hitting the grouping-function-related leak that Andres fixed in 9cf37a527;
but that fix did make it into 11.2 (by just a couple of days...).  Still,
maybe there's another issue in the same area.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-04-15 17:38:48 | Re: Out of Memory errors are frustrating as heck! | 
| Previous Message | Jeff Janes | 2019-04-15 16:51:56 | Re: Out of Memory errors are frustrating as heck! |