| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Suderevsky <psuderevsky(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org, Aleksey Romanov <drednout(dot)by(at)gmail(dot)com> |
| Subject: | Re: PosgreSQL backend process crashed with signal 9 |
| Date: | 2016-04-06 14:46:53 |
| Message-ID: | 30504.1459954013@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Pavel Suderevsky <psuderevsky(at)gmail(dot)com> writes:
> I've faced similar behaviour in much more simple situation. It crashed on
> simple nested loop. And all other child postmaster processes were
> terminated likewise.
>> 2016-04-05 18:37:31 MSK LOG: server process (PID 2848) was terminated by
>> signal 9: Killed
Well, signal 9 is not an internal-to-Postgres error; that's something
outside the database killing the process. If you're on a Linux machine
it's most likely the dreaded OOM killer doing it. The usual
recommendation is to configure your system to reduce or eliminate
memory overcommit:
http://www.postgresql.org/docs/9.5/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
The OP's log did not indicate a signal 9, though --- that was SIGSEGV
(sig 11, typically).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Suderevsky | 2016-04-06 14:53:25 | Re: PosgreSQL backend process crashed with signal 9 |
| Previous Message | Pavel Suderevsky | 2016-04-06 14:36:31 | Re: PosgreSQL backend process crashed with signal 9 |