disk_full could not extend file “…”: No space left on device — 53100

Symptoms

A write needed to grow a relation file but the filesystem holding the data directory is full. PostgreSQL raises SQLSTATE 53100 (disk_full) and the statement (often an INSERT/UPDATE or autovacuum) fails.

• Writes start failing while reads may still work.
• The message names the file that could not be extended.
• Frequently preceded by WAL or temp-file growth filling the volume.

What the server log shows

ERROR:  could not extend file "base/16384/24576": No space left on device
HINT:  Check free disk space.

Why PostgreSQL raises this — what the manual says

Section 30.5 WAL Configuration:

“max_wal_size is never a hard limit anyway, so you should always leave plenty of headroom to avoid running out of disk space.”

Table and index growth requires extending the underlying files. When the filesystem has no free blocks, the extend call fails at the OS level and PostgreSQL surfaces it as 53100, aborting the write to avoid corruption.

Common causes

• Data, WAL, or temp files filling the volume.
• Unbounded WAL growth from an inactive replication slot or archiving failure.
• Large sorts spilling huge temp files.
• Bloat from dead tuples not being vacuumed.

How to fix it

1. Free space immediately (archive/remove old logs, expand the volume).
2. Find and drop inactive replication slots retaining WAL: SELECT * FROM pg_replication_slots WHERE NOT active;.
3. Run VACUUM (and check bloat); cap big sorts with a lower per-session work_mem or temp_file_limit.

Diagnostic query

-- Where is the space going?
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size,
       (SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir()) AS wal_size;

Related & next steps

• SQLSTATE 53100 — Disk Full (full reference)
• Message: could not write to file: No space left on device
• Glossary: WAL

Reference: PostgreSQL 18 Section 30.5 “WAL Configuration”.