From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
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, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Subject: | Re: Out of Memory errors are frustrating as heck! |
Date: | 2019-04-15 17:38:48 |
Message-ID: | 20190415173848.GA9165@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 2019-Apr-15, Gunther wrote:
> #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
> #3 0x0000000000610c83 in ExecHashJoinNewBatch (hjstate=0x11688e0) at nodeHashjoin.c:1042
Seems that ExecHashJoinGetSavedTuple stores a minimalTuple and sets the
shouldFree flag to "true", and then in ExecHashJoinNewBatch, callee
ExecFetchSlotMinimalTuple sets shouldFree to false inconditionally when
the slot uses minimal tuple ops. Maybe that's correct, but it does
sound like a memory leak is not entirely impossible. I wonder if this
fixes it, without causing crashes elsewhere.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
mintup-free.patch | text/x-diff | 460 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-04-15 17:45:00 | Re: Out of Memory errors are frustrating as heck! |
Previous Message | Tom Lane | 2019-04-15 17:32:51 | Re: Out of Memory errors are frustrating as heck! |