From: | Jean-Christophe Boggio <postgresql(at)thefreecat(dot)org> |
---|---|
To: | pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: One PG process eating more than 40GB of RAM and getting killed by OOM |
Date: | 2023-10-13 19:12:02 |
Message-ID: | 416d1607-4650-4624-b8e5-46f8a674aebf@thefreecat.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-10-13 19:38:43 | Re: One PG process eating more than 40GB of RAM and getting killed by OOM |
Previous Message | Jeff Janes | 2023-10-13 16:48:07 | Re: One PG process eating more than 40GB of RAM and getting killed by OOM |