pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Joe Conway <mail@joeconway.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Francisco Olarte <folarte@peoplecall.com>
Cc: tom@quist.de
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17793: Query with large number of joins crashes PostgreSQL
Date: Tue, 14 Feb 2023 10:59:40 -0500
Message-ID: <1975c07f-82a0-3503-e221-211b43878467@joeconway.com> (raw)
In-Reply-To: <1682145.1676386040@sss.pgh.pa.us>
References: <17793-21fa598adbc21118@postgresql.org>
	<CA+bJJbzUKMzkYjGxbQpaRo_evErh+XsnMUUJC+q+edGCM3un8A@mail.gmail.com>
	<1682145.1676386040@sss.pgh.pa.us>

On 2/14/23 09:47, Tom Lane wrote:
> Francisco Olarte <folarte@peoplecall.com> writes:
>> On Tue, 14 Feb 2023 at 11:29, PG Bug reporting form
>> <noreply@postgresql.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






view thread (6+ messages)  latest in thread

Message-ID: <1975c07f-82a0-3503-e221-211b43878467@joeconway.com>
Permalink:  ../1975c07f-82a0-3503-e221-211b43878467@joeconway.com/
Also on:    postgresql.org/message-id/1975c07f-82a0-3503-e221-211b43878467@joeconway.com

 · 

reply

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-bugs@postgresql.org
  Cc: mail@joeconway.com, tgl@sss.pgh.pa.us, folarte@peoplecall.com, tom@quist.de, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #17793: Query with large number of joins crashes PostgreSQL
  In-Reply-To: <1975c07f-82a0-3503-e221-211b43878467@joeconway.com>

* 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