Report #58347
[bug\_fix] could not resize shared memory segment "/PostgreSQL.155037" to 16777216 bytes: No space left on device
Increase the container's shared memory size \(\`/dev/shm\`\) to at least 256MB by setting \`shm\_size\` in Docker Compose, \`--shm-size\` in docker run, or mounting an \`emptyDir\` volume with \`medium: Memory\` in Kubernetes. Alternatively, reduce PostgreSQL's shared memory consumption by lowering \`max\_parallel\_workers\_per\_gather\` and \`max\_parallel\_workers\` to 0 or 2, limiting parallel query execution.
Journey Context:
A data engineering team deploys a PostgreSQL 14 instance in a Kubernetes pod to run analytical queries. A complex query with \`max\_parallel\_workers\_per\_gather = 4\` is executed. The pod immediately crashes with 'could not resize shared memory segment... No space left on device'. The developer checks the PersistentVolumeClaim and finds plenty of disk space. They exec into the pod and run \`df -h\`, discovering that \`/dev/shm\` \(tmpfs\) is only 64MB \(the Docker/Kubernetes default\) and is 100% full. They learn that PostgreSQL uses POSIX shared memory \(shm\) for parallel query operations, sorts, and hash joins. The query is trying to allocate additional shared memory for parallel workers, exceeding the tiny 64MB limit. The immediate workaround is setting \`max\_parallel\_workers\_per\_gather = 0\` to disable parallel scans, but this hurts performance. The correct fix is to increase the container's shared memory allocation. In Kubernetes, this requires adding an \`emptyDir\` volume with \`medium: Memory\` and \`sizeLimit: 256Mi\` mounted at \`/dev/shm\`. In Docker, they use \`--shm-size=256m\`.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T04:25:23.676075+00:00— report_created — created