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

What it means

Parallel queries share data between the leader and its workers through dynamic shared memory segments. On Linux, PostgreSQL creates these as files in /dev/shm, a memory-backed file system. The query asked to grow a segment (here to about 2 MB, for a shared hash table) and /dev/shm had no room:

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

Despite “No space left on device”, your disk is fine: this is memory. The same SQLSTATE (53100, disk full) is used for both, so check the message: a disk problem says could not extend file.

Containers get their own small /dev/shm: 64 MB by default in Docker (some Docker runtimes set it larger). That’s enough for small parallel queries, but a parallel hash join or sort over a few million rows needs more.

Common causes

1. PostgreSQL in Docker or Docker Compose with the default /dev/shm, running analytic queries, big joins or CREATE INDEX with parallel workers.
2. Kubernetes pods, which by default have a small /dev/shm unless you mount a memory-backed volume there.
3. More parallelism than the space allows: raised max_parallel_workers_per_gather or work_mem multiply what each query asks for.

How to fix it

Give the container a bigger /dev/shm

docker run --shm-size=1g … postgres:18

In Docker Compose:

services:
  db:
    image: postgres:18
    shm_size: 1g

The size is a limit, not a reservation: memory is only used while segments exist, and they go away when the query ends. In Kubernetes, mount an emptyDir volume with medium: Memory at /dev/shm.

Check what the container has with df -h /dev/shm inside it.

Or reduce parallelism

For one session or query:

SET max_parallel_workers_per_gather = 0;

Server-wide, a lower max_parallel_workers_per_gather or work_mem reduces what each query needs. This trades the error for slower big queries, so prefer more /dev/shm when you can.

Reproduce it

In a throwaway PostgreSQL 18.6 container started with --shm-size=4m (with 1 MB, initdb itself failed with the same error), two tables of 2 million rows each, and this query:

SELECT count(*) FROM orders o JOIN customers c ON c.id = o.customer_id;

Its plan was a parallel hash join with two workers:

 Finalize Aggregate
   ->  Gather
         Workers Planned: 2
         ->  Partial Aggregate
               ->  Parallel Hash Join
                     Hash Cond: (o.customer_id = c.id)
                     ->  Parallel Seq Scan on orders o
                     ->  Parallel Hash
                           ->  Parallel Seq Scan on customers c

It failed:

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

With \set VERBOSITY verbose the code was 53100. After SET max_parallel_workers_per_gather = 0 the same query returned 1999960. In a new container with --shm-size=256m, the parallel query returned 1999960 without error.

In Inlet

EXPLAIN is drawn as a tree, so you can see whether a query uses parallel workers (a Gather node) before you run it. When a query fails, Inlet shows the server’s error, and What this error means opens this page.