Re: BUG #17793: Query with large number of joins crashes PostgreSQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17793: Query with large number of joins crashes PostgreSQL
Дата
Msg-id 1682145.1676386040@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17793: Query with large number of joins crashes PostgreSQL  (Francisco Olarte <folarte@peoplecall.com>)
Ответы Re: BUG #17793: Query with large number of joins crashes PostgreSQL  (Joe Conway <mail@joeconway.com>)
Re: BUG #17793: Query with large number of joins crashes PostgreSQL  (Francisco Olarte <folarte@peoplecall.com>)
Список pgsql-bugs
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.

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently
Следующее
От: Joe Conway
Дата:
Сообщение: Re: BUG #17793: Query with large number of joins crashes PostgreSQL