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
Re: BUG #17793: Query with large number of joins crashes PostgreSQL |
Список | 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 по дате отправления: