From: Jean-Christophe Boggio <postgresql@thefreecat.org>
To: pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: One PG process eating more than 40GB of RAM and getting killed by OOM
Date: Fri, 13 Oct 2023 21:12:02 +0200
Message-ID: <416d1607-4650-4624-b8e5-46f8a674aebf@thefreecat.org> (raw)
In-Reply-To: <CAMkU=1wx43ex_RsQAH+zaTE5kCo1okoYsEWUaDOkHSJ87iD7Hg@mail.gmail.com>
References: <1018f9c0-9d14-4146-b7e9-24c48ea29e1d@thefreecat.org>
<897a43b3-60d0-2417-f821-9299fd204c1d@sqlexec.com>
<b9a4bf45-65ca-4598-beae-84e269331fbb@thefreecat.org>
<CAMkU=1wx43ex_RsQAH+zaTE5kCo1okoYsEWUaDOkHSJ87iD7Hg@mail.gmail.com>
Le 13/10/2023 à 18:48, Jeff Janes a écrit :
> Yes, turning off overcommit doesn't play with graphical environments,
> in my experience. But a production database probably shouldn't be
> running on a system like that. On non-prod systems, you can either
> turn it off temporarily, or you could try to catch the problem before
> it becomes fatal and get the log with pg_log_backend_memory_contexts.
As I said, this is my dev laptop and no, I would never waste precious
RAM this way on a production server ;-)
> We can see what the problem is (over 137,000 concurrent tuple sorts),
> but we can't tell what is ultimately causing it. You will need to dig
> into, or disclose, the contents of the procedure.
I have no problem disclosing this code and data to the PG dev team (this
is client data though so please keep it for yourselves). Where can I
send you a link to the dump ?
Best,
JC
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: postgresql@thefreecat.org, pgsql-admin@lists.postgresql.org
Subject: Re: One PG process eating more than 40GB of RAM and getting killed by OOM
In-Reply-To: <416d1607-4650-4624-b8e5-46f8a674aebf@thefreecat.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox