Fix: could not resize shared memory segment, No space left on device

This error means a PostgreSQL parallel query worker tried to grow a shared memory segment and the underlying /dev/shm filesystem was full. Parallel workers do not pass their results back through normal memory: they stage tuples in POSIX shared memory, which on Linux lives in the tmpfs mounted at /dev/shm. When that mount is tiny, as it is by default inside containers, a large parallel scan, hash, or sort exhausts it and the worker aborts. Despite the wording, this is not the classic out of shared memory lock table error.

ERROR: could not resize shared memory segment "/PostgreSQL.1234567890" to 2097152 bytes: No space left on device

What this error means

When PostgreSQL runs a query in parallel, the leader and its workers coordinate through a dynamic shared memory segment. On Linux that segment is backed by a file in /dev/shm, a RAM backed tmpfs. The size of what the workers stage there grows with work_mem and the number of parallel workers. If /dev/shm is capped at 64MB (the Docker default) or at a small Kubernetes emptyDir limit, a heavy parallel operation runs out of room and the resize call returns ENOSPC, which surfaces as No space left on device. The failing query aborts, but the server itself keeps running.

Common causes

• Running PostgreSQL in a Docker container with the default 64MB /dev/shm and no --shm-size override.
• A Kubernetes pod whose /dev/shm is a default sized emptyDir, or has no memory backed emptyDir mounted at all.
• Large work_mem combined with several parallel workers, so each gather tries to stage more than /dev/shm can hold.
• Analytic queries with big parallel hash joins or parallel sorts over wide rows.
• max_parallel_workers_per_gather set high on a container that was never given matching shared memory.
• Multiple heavy parallel queries running at once, each competing for the same small /dev/shm.

How to fix it

STABILIZE first. If a single query is failing repeatedly and blocking a job, reduce the memory it demands so it can complete while you arrange a proper shared memory increase.

1. STABILIZE: lower the parallel memory footprint for the session or the offending job so it stops overflowing /dev/shm.

SET work_mem = '32MB';
SET max_parallel_workers_per_gather = 0;

Setting max_parallel_workers_per_gather to 0 disables parallelism for that session, which sidesteps /dev/shm entirely at the cost of speed.

2. DIAGNOSE: confirm how small /dev/shm actually is inside the container or pod.

df -h /dev/shm

A 64MB size on the tmpfs line confirms the container default is the constraint.

3. FIX the capacity for Docker: give the container real shared memory. This requires recreating the container.

docker run --shm-size=1g my-postgres-image

For docker compose, set shm_size: 1gb on the service.

4. FIX the capacity for Kubernetes: mount a memory backed emptyDir at /dev/shm with an explicit size limit.

volumes:
  - name: dshm
    emptyDir:
      medium: Memory
      sizeLimit: 1Gi
volumeMounts:
  - name: dshm
    mountPath: /dev/shm

Note that a Memory medium emptyDir counts against the pod’s memory limit, so size the pod accordingly.

5. FIX the workload if you cannot grow the mount. Lower work_mem and max_parallel_workers_per_gather in postgresql.conf so parallel gathers stage less data, then reload.

ALTER SYSTEM SET work_mem = '32MB';
ALTER SYSTEM SET max_parallel_workers_per_gather = 2;
SELECT pg_reload_conf();

6. Verify by rerunning the query after the container or pod restart and confirming /dev/shm now has headroom.

df -h /dev/shm

How to prevent it

• Set --shm-size (or a Memory emptyDir with sizeLimit) on every containerized PostgreSQL, do not rely on the 64MB default.
• Size /dev/shm to match your work_mem and parallel worker settings, allowing headroom for concurrent parallel queries.
• Treat work_mem as a per operation, per worker budget: a high value multiplies fast under parallelism.
• Test the heaviest analytic queries against the container limits before shipping, not only against a laptop with a large /dev/shm.
• Alert on /dev/shm usage so you see pressure before a query fails.

When to call a senior engineer

Call for help when raising /dev/shm still leaves queries failing, when you cannot balance shared memory against the pod’s overall memory limit, or when tuning parallelism to fit the container quietly wrecks query performance. Erzon engineers can right size /dev/shm, work_mem, and parallel settings together for your workload, and stop containerized PostgreSQL from failing analytics under load.