From: Tom Lane <tgl@sss.pgh.pa.us>
To: Francisco Olarte <folarte@peoplecall.com>
cc: tom@quist.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17793: Query with large number of joins crashes PostgreSQL
In-reply-to: 
 <CA+bJJbzUKMzkYjGxbQpaRo_evErh+XsnMUUJC+q+edGCM3un8A@mail.gmail.com>
References: <17793-21fa598adbc21118@postgresql.org>
 <CA+bJJbzUKMzkYjGxbQpaRo_evErh+XsnMUUJC+q+edGCM3un8A@mail.gmail.com>
Comments: In-reply-to Francisco Olarte <folarte@peoplecall.com>
	message dated "Tue, 14 Feb 2023 12:51:02 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1682144.1676386040.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Feb 2023 09:47:20 -0500
Message-ID: <1682145.1676386040@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1682145.1676386040%40sss.pgh.pa.us>
Precedence: bulk

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 i=
s 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.

			regards, tom lane