Re: One PG process eating more than 40GB of RAM and getting killed by OOM

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