Re: Out of Memory errors are frustrating as heck!
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gunther <raj@gusw.net>
Cc: Jeff Janes <jeff.janes@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
pgsql-performance@lists.postgresql.org,
Justin Pryzby <pryzby@telsasoft.com>
Date: 2019-04-15T17:32:51Z
Lists: pgsql-performance
Gunther <raj@gusw.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@entry=0x8bbc528, hashvalue=hashvalue@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
Commits
-
Consider BufFiles when adjusting hashjoin parameters
- a1b4f289beec 18.0 landed
-
Allocate hash join files in a separate memory context
- 8c4040edf456 16.0 landed