From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 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 14:47:20 |
Message-ID: | 1682145.1676386040@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2023-02-14 15:59:40 | Re: BUG #17793: Query with large number of joins crashes PostgreSQL |
Previous Message | Dean Rasheed | 2023-02-14 13:22:00 | Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently |