Yes, OOM killer did the job, but is it normal that so lightweight query is
consuming so much memory that OOM-killer to be invoked?
> [dbtest3] mars_gedik=# select
> pg_size_pretty(pg_relation_size('node_statuses'));
> pg_size_pretty
> ----------------
> 11 MB
> (1 row)
> [dbtest3] mars_gedik=# select
> pg_size_pretty(pg_relation_size('node_status_values'));
> pg_size_pretty
> ----------------
> 11 MB
> (1 row)
2016-04-06 17:46 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Suderevsky <psuderevsky@gmail.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
>