Erreur PostgreSQL : No space left on device

SQLSTATE 53100 (disk_full) · Mis à jour 9 juillet 2026

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

Le système de fichiers hébergeant la base n'a plus de place. Les écritures commencent à échouer ; si le WAL lui-même ne peut plus être écrit, le serveur fera un PANIC et s'arrêtera. Une règle avant tout : ne supprimez jamais manuellement de fichiers dans le répertoire de données — surtout pas pg_wal. Ce chemin mène d'une panne à une restauration.

Ce que signifie cette erreur

Un disque plein sur un hôte PostgreSQL a une courte liste de suspects habituels, et le plus instructif est la rétention de WAL : pg_wal s'auto-nettoie en fonctionnement normal, donc quand il grossit sans limite, quelque chose dit à PostgreSQL de conserver le WAL. Les deux raisons classiques : un archive_command qui échoue (le WAL ne peut pas être recyclé tant qu'il n'est pas archivé) et un slot de réplication inactif — un réplica mis hors service sans supprimer son slot garde le WAL épinglé pour toujours.

Causes fréquentes

• Slot de réplication obsolète ou archivage WAL cassé épinglant pg_wal.
• Simple croissance des données ayant dépassé le volume.
• Fichiers temporaires de tris/hachages énormes (une seule mauvaise requête peut écrire des centaines de Go de temp).
• Journaux — journalisation verbeuse sans rotation.

Comment la diagnostiquer

# Où sont passés les Go :
df -h
du -sh /var/lib/postgresql/*/main/*   # base/ pg_wal/ log/ ...

-- Slots qui retiennent du WAL (regardez active=f et combien ils retiennent) :
SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

-- Requêtes qui écrivent trop de fichiers temporaires (activez log_temp_files pour l'historique) :
SELECT datname, temp_files, pg_size_pretty(temp_bytes) FROM pg_stat_database;

Comment la corriger

• Libérez d'abord de l'espace en dehors du répertoire de données (anciens journaux, paquets, fichiers sans rapport) pour que le serveur puisse respirer, puis corrigez la vraie cause.
• Slot obsolète → SELECT pg_drop_replication_slot('old_replica'); — le WAL est recyclé en quelques checkpoints. Archivage cassé → corrigez archive_command et regardez l'arriéré se résorber.
• Plafonnez les modes d'échec pour l'avenir : max_slot_wal_keep_size (PostgreSQL 13+) borne la quantité de WAL qu'un slot peut retenir ; temp_file_limit borne l'usage de temp des requêtes emballées ; la rotation des journaux pour les logs.
• Agrandissez le volume quand la cause est une honnête croissance des données — et ajoutez des alertes d'espace disque avec assez de marge pour agir calmement la prochaine fois.