From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Francisco Olarte <folarte(at)peoplecall(dot)com> |
Cc: | tom(at)quist(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17793: Query with large number of joins crashes PostgreSQL |
Date: | 2023-02-14 15:59:40 |
Message-ID: | 1975c07f-82a0-3503-e221-211b43878467@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2/14/23 09:47, Tom Lane wrote:
> Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
>> On Tue, 14 Feb 2023 at 11:29, PG Bug reporting form
>> <noreply(at)postgresql(dot)org> wrote:
>>> It looks like the OS is killing the process due to running OOM, which is not
>>> very surprising when looking at the query. Is this expected, or should PG
>>> have guards in place to prevent this from happening?
>
>> When you run postgres in an environment where someone ( OOM killer )
>> can K9 it, protection is hard. IIRC OOM can kill you because ANOTHER
>> process touches memory, among other things.
>
> Yeah. We have no visibility into what the OOM killer will choose to
> allow or not allow at any instant.
>
>> ( I do run DBs in machines w/ overcommit disabled, this prevents it
>> from happening, but it is not Pg who prevents it ).
>
> If overcommit-disabled doesn't seem practical, another idea that's
> been recommended is to start the postmaster under a "ulimit -v"
> setting chosen to cause plain ENOMEM failures before the OOM
> killer kicks in.
Given:
> It looks like the OS is killing the process due to running OOM ...
> I could reproduce it using a fresh docker container of the image
> "postgres:13.10".
I gather the OP is running Postgres in a container. If so, and if they
have a memory.limit set (also assuming cgroup v1, otherwise memory.max
for cgroup v2), disabling overcommit at the host level will not prevent
an OOM kill when the cgroup exceeds memory.limit
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-14 16:26:51 | Re: BUG #17782: ERROR: variable not found in subplan target lists |
Previous Message | Tom Lane | 2023-02-14 14:47:20 | Re: BUG #17793: Query with large number of joins crashes PostgreSQL |