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>, pgsql-performance@lists.postgresql.org,
Justin Pryzby <pryzby@telsasoft.com>
Date: 2019-04-15T15:53:38Z
Lists: pgsql-performance
I wrote: > If you can use gdb at all, it's not that hard to break on allocations > into a specific context; I've done it many times. The strategy is > basically > 1. Let query run long enough for memory usage to start increasing, > then attach to backend with gdb. BTW, just to clarify that strategy a bit: the usage pattern we expect for ExecutorState is that there are a bunch of individual allocations during executor startup, but then none while the query is running (or at least, if there are any in that phase, they get freed before moving on to the next row). The form of the leak, almost certainly, is that some allocation is happening per-row and *not* getting freed. So there's no point in groveling through the startup behavior. What we want to know about is what happens after we reach the ought-to-be steady state behavior. 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