Original-Subject: Re: One PG process eating more than 40GB of RAM and getting
 killed by
 OOM
Original-From: Jean-Christophe Boggio <postgresql@thefreecat.org>
Message-ID: <416d1607-4650-4624-b8e5-46f8a674aebf@thefreecat.org>
Date: Fri, 13 Oct 2023 21:12:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: One PG process eating more than 40GB of RAM and getting killed by
 OOM
To: pgsql-admin <pgsql-admin@lists.postgresql.org>
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>
Content-Language: fr-FR, en-US
From: Jean-Christophe Boggio <postgresql@thefreecat.org>
In-Reply-To: 
 <CAMkU=1wx43ex_RsQAH+zaTE5kCo1okoYsEWUaDOkHSJ87iD7Hg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/416d1607-4650-4624-b8e5-46f8a674aebf%40thefreecat.org>
Precedence: bulk

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