Introduction
Pendant près de quinze ans, activer les checksums de données sur un cluster PostgreSQL existant impliquait une contrainte incontournable : l'arrêt complet du service. L'outil pg_checksums, introduit en PostgreSQL 12, a rendu l'opération plus supportable, mais le downtime restait obligatoire. Pour les équipes opérant en 24/7, les options se résumaient à trois scénarios peu enviables : accepter une fenêtre de maintenance, basculer sur un replica déjà checksum, ou tout simplement vivre sans cette protection.
PostgreSQL 19 change la donne avec l'activation en ligne des checksums. Un commit de Daniel Gustafsson (3 avril 2026) introduit la possibilité d'activer ou de désactiver les checksums sans arrêter le cluster. La commande SQL retourne immédiatement, le cluster continue de servir le trafic — et un processus d'arrière-plan se charge de réécrire silencieusement chaque page heap et index.
C'est une avancée majeure. C'est aussi une fonctionnalité qui peut vous brûler si vous la traitez comme un simple switch instantané.
Source originale : Online Checksums Are Not Instant — Christophe Pettus
Ce qui se passe réellement sous le capot
Lorsque vous exécutez la commande d'activation, rien ne change sur le disque à cet instant. Ce que vous venez de faire, c'est basculer un état au niveau du cluster. Le vrai travail commence ensuite :
- Un processus d'arrière-plan parcourt chaque relation (tables, index).
- Il lit chaque page en mémoire (shared buffers), y inscrit le checksum, et réécrit la page sur disque.
- Toutes ces opérations passent par le WAL (Write-Ahead Log).
Conséquences directes :
- Le trafic de réplication augmente significativement pendant toute la durée de la conversion.
- L'empreinte de vos sauvegardes (WAL archivés) grossit en proportion.
- Si le processus est interrompu en cours de route, le cluster se retrouve dans un état mixte : certaines pages checksumées, d'autres non. Cet état est sûr, mais le statut visible des checksums ne passe pas à
on tant que la conversion n'est pas terminée.
Ne pas surveiller ce processus, c'est prendre le risque de rester indéfiniment dans cet état hybride sans le savoir.
Checklist opératoire avant d'activer
Voici les étapes à suivre pour une activation maîtrisée en production.
1. Mesurer votre baseline WAL
Avant de lancer quoi que ce soit, établissez un point de référence :
-- Volume WAL généré sur une période de référence
SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0'));
Pendant la conversion, attendez-vous à un pic significatif. Sur un cluster multi-téraoctets avec un bon provisionnement IOPS, la conversion durera plusieurs heures. Planifiez en conséquence.
2. Tester sur un replica d'abord
Ne lancez jamais cette opération en premier sur votre primaire. Testez sur un replica de staging ou de pré-production :
- Mesurez la durée réelle sur un volume de données représentatif.
- Observez l'impact sur le lag de réplication.
- Vérifiez que vos outils de monitoring n'interprètent pas le spike WAL comme une anomalie.
3. Planifier la fenêtre I/O
L'impact disque se rapproche d'un VACUUM FULL sur l'ensemble du cluster — pas d'une simple mise à jour mineure. Évitez de lancer la conversion :
- Pendant vos pics de charge applicative.
- Juste avant une fenêtre de backup complète.
- En même temps qu'une autre opération lourde (réindexation, autovacuum intensif).
Si votre infrastructure le permet, envisagez de réduire temporairement max_wal_size ou d'augmenter la capacité d'archivage WAL.
4. Monitorer le lag de réplication
Pendant la conversion, surveillez en continu :
-- Sur le primaire : vérifier le lag des replicas
SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
(sent_lsn - replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;
Un lag qui s'emballe peut indiquer que vos replicas n'absorbent pas le volume WAL supplémentaire. Soyez prêts à throttler ou à mettre en pause si nécessaire.
5. Vérifier l'état de progression
PostgreSQL 19 expose l'état de la conversion via les vues système. Consultez régulièrement :
-- Vérifier le statut global des checksums
SHOW data_checksums;
-- Vue pg_stat_checksums (à confirmer selon la doc finale de PG19)
SELECT * FROM pg_stat_checksums;
6. Rollback-safe : ce que vous devez savoir
L'activation est réversible. Vous pouvez lancer la désactivation sur un cluster en état mixte. Cependant :
- La désactivation déclenche elle aussi un processus de réécriture complet (en sens inverse).
- Deux opérations lourdes consécutives sur un cluster de production, c'est un risque opérationnel supplémentaire.
- Testez votre procédure de rollback en staging avant d'en avoir besoin en urgence.
Ce que ça change pour vos sauvegardes
Si vous utilisez pgBackRest, Barman ou pg_basebackup, la conversion va gonfler le volume WAL archivé. Deux points d'attention :
- Capacité de stockage WAL : vérifiez que votre retention et votre espace d'archivage peuvent absorber le surplus.
- Cohérence des sauvegardes : une sauvegarde prise pendant une conversion en état mixte est valide, mais la restauration aboutira à un cluster également en état mixte. Prévoyez de relancer la conversion après restauration si nécessaire.
Conclusion
L'activation en ligne des checksums dans PostgreSQL 19 est l'une des améliorations opérationnelles les plus attendues de ces dernières années. Elle supprime enfin l'obligation de downtime pour sécuriser l'intégrité des données à bas niveau — une contrainte qui avait rendu cette protection inaccessible pour beaucoup d'équipes en production continue.
Mais « en ligne » ne signifie pas « sans impact ». La commande SQL est instantanée ; la conversion, elle, est un marathon I/O et WAL. Traitez-la avec le même sérieux qu'une migration de schéma majeure : baseline avant, test sur replica, monitoring continu, fenêtre planifiée.
Activez les checksums. Mais faites-le avec les yeux ouverts.
