PostgreSQL-Fehler: No space left on device

SQLSTATE 53100 (disk_full) · Aktualisiert 9. Juli 2026

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

Das Dateisystem, das die Datenbank beherbergt, hat keinen Platz mehr. Schreibvorgänge beginnen fehlzuschlagen; wenn das WAL selbst nicht geschrieben werden kann, geht der Server in PANIC und fährt herunter. Eine Regel vor allem anderen: löschen Sie nie manuell Dateien innerhalb des Datenverzeichnisses — besonders pg_wal. Dieser Weg führt von einem Ausfall zu einem Restore.

Was dieser Fehler bedeutet

Volle Platte auf einem PostgreSQL-Host hat eine kurze Liste üblicher Verdächtiger, und der lehrreichste ist WAL-Retention: pg_wal reinigt sich im Normalbetrieb selbst, wenn es also unbegrenzt wächst, sagt etwas PostgreSQL, das WAL zu behalten. Die zwei klassischen Gründe: ein fehlschlagendes archive_command (WAL kann nicht recycelt werden, bis es archiviert ist) und ein inaktiver Replikations-Slot — eine Replika, die außer Betrieb genommen wurde, ohne ihren Slot zu droppen, hält WAL für immer angeheftet.

Häufige Ursachen

• Veralteter Replikations-Slot oder kaputtes WAL-Archiving, das pg_wal anheftet.
• Schlichtes Datenwachstum, das das Volume überholt hat.
• Temporäre Dateien aus riesigen Sorts/Hashes (eine einzige schlechte Query kann Hunderte GB an Temp schreiben).
• Logs — ausführliches Logging ohne Rotation.

So diagnostizieren Sie ihn

# Wohin die GB gegangen sind:
df -h
du -sh /var/lib/postgresql/*/main/*   # base/ pg_wal/ log/ ...

-- Slots, die WAL zurückhalten (achten Sie auf active=f und wie viel sie zurückhalten):
SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

-- Queries, die zu viele temporäre Dateien schreiben (aktivieren Sie log_temp_files für die Historie):
SELECT datname, temp_files, pg_size_pretty(temp_bytes) FROM pg_stat_database;

So beheben Sie ihn

• Schaffen Sie zuerst Platz außerhalb des Datenverzeichnisses (alte Logs, Pakete, nicht verwandte Dateien), damit der Server durchatmen kann, und beheben Sie dann die eigentliche Ursache.
• Veralteter Slot → SELECT pg_drop_replication_slot('old_replica'); — WAL wird innerhalb weniger Checkpoints recycelt. Kaputtes Archiving → beheben Sie archive_command und beobachten Sie, wie der Rückstau abfließt.
• Begrenzen Sie die Fehlermodi für die Zukunft: max_slot_wal_keep_size (PostgreSQL 13+) begrenzt, wie viel WAL ein Slot zurückhalten darf; temp_file_limit begrenzt entlaufenen Query-Temp-Verbrauch; Log-Rotation für die Logs.
• Vergrößern Sie das Volume, wenn die Ursache ehrliches Datenwachstum ist — und fügen Sie Speicherplatz-Alarmierung mit genug Spielraum hinzu, um das nächste Mal ruhig handeln zu können.