PostgreSQL "could not resize shared memory segment": Where Does Memory Run Out?
The Docker /dev/shm 64MB default limit, parallel query shared memory exhaustion, proper work_mem calculation, and ordered remediation.
Operational Verification & Reliability Metadata
The error string is a symptom, not the root cause. Do not restart the server blindly. Run the diagnostic queries below to pinpoint the actual failure mode.
▸Symptoms
ERROR: could not resize shared memory segment: No space left on device
ERROR: out of memoryThe issue is almost universally Docker's default 64MB mount for /dev/shm.
▸Ordered Fix
- 1Adjust Docker `--shm-size`: Set
--shm-size=1gor indocker-compose.yml:
services:
postgres:
shm_size: 1gb- 1Emergency Query Throttle: Disable parallel gathering temporarily:
SET max_parallel_workers_per_gather = 0;- 1Audit `work_mem` Formula:
work_mem ≈ (RAM - shared_buffers) / (max_connections * 3)Other Database Error Triage Playbooks
Other battle-tested diagnostic guides for high-severity database errors.
PostgreSQL too many clients already: 6-Step Resolution
Three root causes of FATAL: sorry, too many clients already, single diagnostic query to identify the cause, and permanent mitigation via max_connections and PgBouncer.
PostgreSQL password authentication failed: Root Cause and Fix
Four root causes of psql password authentication failed: incorrect password, md5/SCRAM mismatch, pg_hba.conf rule ordering, and port/cluster confusion. Step-by-step triage.
PostgreSQL connection refused: 8-Step Definitive Triage
Difference between connection refused, timeout, and no pg_hba entry; triage for listen_addresses, port conflicts, firewalls, and Docker container mappings.