Bonjour,
Votre diagnostic est correct : l’accumulation des fichiers WAL dans pg_wal est due à un slot de réplication logique inactif dont le confirmed_flush_lsn n’avance plus. PostgreSQL ne peut pas nettoyer les WAL tant qu’un slot logique déclare en avoir besoin. La procédure recommandée consiste à identifier précisément le slot orphelin, vérifier qu’aucun processus actif ne l’utilise, puis le supprimer avec pg_drop_replication_slot().
Commencez par lister les slots existants avec :
sql
SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;
Un slot logique inactif apparaîtra avec active = false et un confirmed_flush_lsn bloqué. Avant de le supprimer, assurez-vous qu’aucun processus de réplication ou de consommation logique n’est en cours. Vous pouvez vérifier les connexions actives avec :
sql
SELECT pid, usename, application_name, state
FROM pg_stat_activity
WHERE backend_type = 'walsender';
Si aucun processus n’est lié au slot en question, vous pouvez le supprimer en toute sécurité :
sql
SELECT pg_drop_replication_slot('nom_du_slot');
Cette commande libère immédiatement les WAL retenus par ce slot. Il est important de ne jamais supprimer un slot actif, car cela provoquerait une perte de continuité pour le consommateur logique associé. Si vous avez un doute, arrêtez temporairement les services applicatifs qui pourraient utiliser la réplication logique, puis relancez-les après suppression du slot.
Pour éviter que la situation ne se reproduise, je recommande de mettre en place une surveillance régulière des slots via pg_replication_slots et d’automatiser la détection des slots inactifs. Dans les environnements où les slots logiques sont créés dynamiquement, il est préférable de définir une politique interne de nettoyage ou d’utiliser des outils comme pglogical qui gèrent mieux la durée de vie des slots.
DV.