Out of memory

Symptom: server process (PID n) was terminated by signal 9: Killed, all connections dropping at once, or out of memory errors on a query.

Signal 9 means the operating system's OOM killer ended a Postgres process, and Postgres then restarts everything to be safe. The OS log (dmesg, journalctl -k) confirms it. It is not visible over SQL.

Why it happens

work_mem is a limit per sort or hash node, per query, per connection. A query with three such nodes on 200 connections can ask for 600 times work_mem.

Rough worst case: shared_buffers + connections × work_mem × nodes + autovacuum_max_workers × maintenance_work_mem. If that exceeds RAM, one busy hour can trigger the killer.

Confirm your settings

select name, setting, unit from pg_settings
where name in ('shared_buffers','work_mem','maintenance_work_mem','max_connections','hash_mem_multiplier','autovacuum_max_workers');

Fix

1. Lower global work_mem (4 to 16 MB is common) and raise it only for the roles or queries that need it:

   alter role reporting set work_mem = '256MB';
   

2. Cut connection count with a pooler. Each backend also carries its own overhead.
3. Keep shared_buffers around 25% of RAM on a dedicated server.
4. On Linux, set vm.overcommit_memory = 2 and enable huge_pages so allocation failures show up as errors on one query and not as a killed server.
5. Look for the query that got big: pg_stat_statements sorted by temp_blks_written and shared_blks_read.