Horton

Re: Out of Memory errors are frustrating as heck!

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Gunther <raj@gusw.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Janes <jeff.janes@gmail.com>, pgsql-performance@postgresql.org
Date: 2019-04-15T01:48:11Z
Lists: pgsql-performance 
On Sun, Apr 14, 2019 at 09:05:48PM -0400, Gunther wrote:
> Thanks for looking at my problem Tom Lane and Jeff Janes. Sorry for not
> having given enough detail.
> 
> The version is 10.2 latest.

v10.7 is available; could you upgrade ?

What are these set to ?  shared_buffers? work_mem?

Was postgres locally compiled, packaged by distribution, or PGDG RPM/DEB ?

Can you show \d businessoperation ?

> The short version is:
> 
> Grand total: 1437014672 bytes in 168424 blocks; 11879744 free (3423 chunks); 1425134928 used
> 2019-04-14 16:38:26.355 UTC [11061] ERROR:  out of memory
> 2019-04-14 16:38:26.355 UTC [11061] DETAIL:  Failed on request of size 8272 in memory context "ExecutorState".

Could you rerun the query with \set VERBOSITY verbose to show the file/line
that's failing ?

If you wanted to show a stack trace, you could attach gdb to PID from SELECT
pg_backend_pid(), "b"reak on errdetail, run the query, and then "bt" when it
fails.

Justin

Commits

  1. Consider BufFiles when adjusting hashjoin parameters

  2. Allocate hash join files in a separate memory context