How to fix Could not extend file: No space left on device in PostgreSQL

PostgreSQLINTERMEDIATECRITICALUpdated Dec 28, 2025· 203 views

PostgreSQL cannot write new data because the underlying filesystem has exhausted its storage capacity. Resolve this by freeing disk space, cleaning up temporary files, or increasing available storage.

Quick fix

Fixes Could not extend file: No space left on device

# Check disk usage for entire filesystem
df -h

# Check PostgreSQL data directory size
du -sh /var/lib/pgsql/data

# Or for non-standard installations
du -sh $PGDATA
  1. Check current disk usage immediately
  2. Stop non-critical connections to prevent further writes
  3. Delete or truncate logs to recover space immediately
  4. Clean up temporary files in pgsql_tmp
postgresql — error
# Check disk usage for entire filesystem
df -h
# Check PostgreSQL data directory size
du -sh /var/lib/pgsql/data
# Or for non-standard installations
du -sh $PGDATA
Could not extend file: No space left on device

What this error means

This error occurs when PostgreSQL attempts to extend a data file but encounters an ENOSPC (no space) error from the operating system. The database cannot allocate new space for tables, indexes, or write-ahead logs (WAL). This is a critical condition that can lead to database corruption, failed transactions, and complete service unavailability if unresolved. Unlike application errors that allow some operations to continue, a full disk forces PostgreSQL into an unsafe state where even cleanup operations like VACUUM may fail.

Typical symptoms

  • INSERT, UPDATE, or DELETE queries fail with "could not extend file" error
  • Autovacuum processes crash or are unable to run
  • PostgreSQL service crashes or becomes unresponsive
  • Replication lags or fails to synchronize
  • Backup operations timeout or fail
  • pg_wal directory grows uncontrollably
  • Temporary files in pg_temp accumulate and are not cleaned up

Common causes

  1. Actual disk exhaustion: The filesystem where PostgreSQL data resides is completely full
  2. WAL accumulation: Write-ahead logs (pg_wal) filling disk due to failed replication slots or archive commands
  3. Temporary file overflow: Large sorts, hashes, or aggregations spilling to disk (pgsql_tmp)
  4. Uncontrolled table growth: Autovacuum not tuned properly, leaving dead rows in heap
  5. Log file bloat: PostgreSQL logs (pg_log) growing without rotation or cleanup
  6. File system fragmentation: XFS or other filesystems with suboptimal allocation groups reporting ENOSPC despite available space

How to fix "Could not extend file: No space left on device"

1Check current disk usage immediately

First, verify that PostgreSQL is actually out of disk space and identify which filesystem is full:

bash
# Check disk usage for entire filesystem
df -h

# Check PostgreSQL data directory size
du -sh /var/lib/pgsql/data

# Or for non-standard installations
du -sh $PGDATA

Look for a filesystem showing 100% or near-full usage. If the system disk (/dev/root) is full, you have OS-level problems.

2Stop non-critical connections to prevent further writes

Connect as a superuser and terminate idle connections. DO NOT kill long-running transactions abruptly:

sql
-- See active connections
SELECT pid, usename, state, query FROM pg_stat_activity;

-- Terminate idle connections only
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
  AND pid <> pg_backend_pid();

This prevents new writes from consuming remaining space while you work.

3Delete or truncate logs to recover space immediately

The fastest way to recover disk space is removing log files. PostgreSQL logs can grow to gigabytes:

bash
# Find and remove old log files (keep last 3 days for debugging)
find /var/lib/pgsql/data/pg_log -type f -mtime +3 -delete

# Or if using syslog, check system logs
find /var/log -name '*postgres*' -mtime +7 -delete

# Verify space recovery
df -h

Only delete logs older than the retention period you're comfortable with.

4Clean up temporary files in pgsql_tmp

If queries crashed before completing, temporary files may linger:

bash
# List temporary files
ls -lh /var/lib/pgsql/data/base/pgsql_tmp/

# Remove them (safe if PostgreSQL is idle)
rm -rf /var/lib/pgsql/data/base/pgsql_tmp/*

# Restart PostgreSQL to ensure clean state
sudo systemctl restart postgresql

Temporary files are safe to delete as they're only used during query execution.

5Check for and resolve problematic replication slots

Replication slots prevent WAL cleanup, causing pg_wal to fill disk. Identify problematic slots:

sql
-- List all replication slots and their retention
SELECT slot_name, slot_type, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;

-- Check which WAL files are retained
SELECT * FROM pg_ls_waldir()
ORDER BY modification DESC LIMIT 10;

-- Drop abandoned slots (replicas that won't reconnect)
SELECT pg_drop_replication_slot('slot_name');

Only drop slots for standby servers you've permanently decommissioned.

6Run VACUUM to reclaim space within tables

After freeing disk space, vacuum tables to reclaim space from deleted rows:

sql
-- Standard VACUUM (non-blocking, available for reads)
VACUUM ANALYZE;

-- For critical tables, use VACUUM FULL (exclusive lock, offline recommended)
VACUUM FULL my_large_table;

Standard VACUUM only makes space available within the table. VACUUM FULL returns unused space to the OS but locks the table exclusively.

7Increase disk capacity for long-term resolution

Temporary cleanup is not enough for sustainable operations:

For cloud environments (AWS RDS, Azure Database for PostgreSQL):
- Enable storage autoscaling in console
- Monitor FreeStorageSpace CloudWatch metrics
- Set up alerts at 20-30% full

For self-hosted PostgreSQL:
- Add a new volume if expansion is possible
- Move data or WAL to separate filesystem
- Use LVM to expand existing volume

Example: Add tablespace on new disk

sql
CREATE TABLESPACE fast_disk LOCATION '/mnt/new_disk/pgdata';
ALTER TABLE large_table SET TABLESPACE fast_disk;

This distributes load and prevents single disk exhaustion.

Advanced notes

PostgreSQL 13+: max_slot_wal_keep_size - Limit WAL retention to prevent unbounded growth:

bash
max_slot_wal_keep_size = 10GB

Separate filesystems are essential: Never store data and pg_wal on the same disk. If pg_wal fills, PostgreSQL panics and shuts down. Isolating it allows controlled degradation.

Autovacuum tuning - Default settings are conservative for small databases:

bash
autovacuum_vacuum_scale_factor = 0.05  # 5% of table
autovacuum_analyze_scale_factor = 0.02
autovacuum_naptime = 1min

WARNING: Never delete WAL files directly. Even one missing WAL segment corrupts your database permanently. Only use pg_drop_replication_slot() to allow proper WAL cleanup.

Docker on macOS: The Linux VM's disk can be full even if your Mac has free space. Docker Desktop Settings > Resources > Disk image size must be increased.

XFS filesystems: Rare but documented cases report ENOSPC errors with available space due to allocation group fragmentation. Use xfs_info to diagnose and consider rebalancing or ext4 alternatives.

Frequently asked questions

What does "Could not extend file: No space left on device" mean?
This error occurs when PostgreSQL attempts to extend a data file but encounters an ENOSPC (no space) error from the operating system. The database cannot allocate new space for tables, indexes, or write-ahead logs (WAL). This is a critical condition that can lead to database corruption, failed transactions, and complete service unavailability if unresolved.
How do I fix "Could not extend file: No space left on device"?
PostgreSQL cannot write new data because the underlying filesystem has exhausted its storage capacity. Resolve this by freeing disk space, cleaning up temporary files, or increasing available storage.
What causes "Could not extend file: No space left on device"?
Actual disk exhaustion: The filesystem where PostgreSQL data resides is completely full WAL accumulation: Write-ahead logs (pg_wal) filling disk due to failed replication slots or archive commands Temporary file overflow: Large sorts, hashes, or aggregations spilling to disk (pgsql_tmp)
Is the "Could not extend file: No space left on device" error serious?
Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading