PostgreSQL 19 : Activation des checksums à chaud, sans interruption de service

Introduction

Jusqu'à présent, activer les checksums de données sur un cluster PostgreSQL imposait un choix inconfortable : soit le faire dès l'initialisation via initdb, soit mettre le cluster hors ligne avec l'utilitaire pg_checksums. Dans les deux cas, une fenêtre de maintenance était inévitable.

Avec PostgreSQL 19, cette contrainte disparaît. Le commit de Daniel Gustafsson du 3 avril 2026 introduit l'activation et la désactivation des checksums en ligne, sur un cluster en production, sans couper l'accès aux bases. C'est une avancée significative pour les équipes qui gèrent des environnements critiques ou des infrastructures conteneurisées.

Source originale : depesz.com – Waiting for PostgreSQL 19 – Online enabling and disabling of data checksums

Comment fonctionne le background worker ?

Le mécanisme repose sur un launcher process dédié qui orchestre des workers dynamiques, un par base de données. Voici le déroulement :

1. Déclenchement : l'activation est demandée (via une future commande SQL ou GUC, les détails exacts seront documentés dans les release notes finales).
2. Marquage des buffers : le worker par base parcourt toutes les relations avec stockage physique et marque leurs buffers comme dirty, forçant leur réécriture sur disque.
3. Calcul des checksums à l'écriture : pendant cette phase, tous les backends (y compris les processus concurrents normaux) écrivent les checksums dans les pages mais ne les vérifient pas encore en lecture.
4. Basculement atomique : une fois toutes les relations de toutes les bases traitées, le GUC data_checksums passe à on. Un procsignalbarrier est propagé à tous les backends.
5. Vérification active : seulement après avoir absorbé ce signal, chaque backend commence à vérifier les checksums en lecture. La transition est donc progressive et sans fenêtre d'incohérence.

Le processus de désactivation suit la même logique en sens inverse.

Point clé : à aucun moment le cluster n'est rendu inaccessible. Les connexions clientes continuent de fonctionner normalement tout au long de l'opération.

Impact I/O : à quoi s'attendre ?

L'activation en ligne n'est pas gratuite en termes de ressources. Voici les effets à anticiper :

• Augmentation des écritures disque : tous les buffers des relations sont marqués dirty et réécrits. Sur une base volumineuse, cela génère un pic d'I/O significatif, comparable à un CHECKPOINT massif étalé dans le temps.
• Pression sur le shared_buffers : le processus de marquage mobilise le buffer pool. Sur des clusters avec peu de RAM, cela peut augmenter les évictions de pages chaudes.
• Charge CPU modérée : le calcul du checksum (CRC32c) est léger par page, mais répété sur l'ensemble du stockage, il s'accumule.
• Réplication : les pages réécrites génèrent du WAL supplémentaire. Les replicas en streaming absorberont ce volume. Surveillez le lag de réplication pendant l'opération.

⚠️ Recommandation : planifiez l'activation pendant une période de faible charge, même si le cluster reste disponible. Le worker s'exécute en arrière-plan, mais il concurrence les I/O normales.

Checklist : intégrer l'activation live dans Docker et Kubernetes

Avant l'activation

• Vérifier la version : s'assurer que l'image Docker utilise PostgreSQL 19+.

  docker exec <container> psql -U postgres -c 'SELECT version();'
  

• Snapshot ou backup : prendre un backup physique (pg_basebackup) ou un snapshot du volume avant toute opération.
• Monitorer les métriques de base : établir un baseline I/O avec pg_stat_bgwriter, pg_stat_io (PG 16+) et les métriques du stockage sous-jacent (IOPS, latence).
• Vérifier le lag de réplication : s'assurer que les replicas sont à jour (pg_stat_replication).

Pendant l'activation

• Suivre la progression du worker via les vues système (les détails exacts seront disponibles dans la documentation PG 19, probablement via pg_stat_activity ou une vue dédiée).
• Alertes I/O : configurer un seuil d'alerte sur les IOPS et la latence d'écriture (seuil recommandé : +50 % par rapport au baseline).
• Surveiller le lag de réplication : un lag croissant peut indiquer que les replicas peinent à absorber le WAL supplémentaire.
• Kubernetes : si le cluster tourne sur un PersistentVolume de type réseau (EBS, Persistent Disk), les IOPS provisionnées peuvent devenir un goulot d'étranglement. Envisagez de scaler temporairement le type de volume ou de limiter le worker via les paramètres de throttling à venir.

Après l'activation

• Vérifier l'état :

  SHOW data_checksums;
  -- Doit retourner 'on'
  

• Valider sur les replicas : vérifier que le paramètre est bien propagé et actif.
• Comparer les métriques : retour à la normale des I/O ? Si non, investiguer un éventuel checkpoint storm résiduel.
• Documenter la date d'activation dans le runbook de l'infrastructure.

Rollback

Si l'impact I/O s'avère trop important, la désactivation suit le même processus en sens inverse. Aucun redémarrage n'est requis. Cependant, notez que désactiver les checksums réduit les garanties d'intégrité des données : à réserver aux cas où l'impact opérationnel est réellement bloquant.

Conclusion

L'activation en ligne des checksums dans PostgreSQL 19 lève une contrainte qui pesait sur les équipes DBA depuis des années. Pour les environnements Docker et Kubernetes où les arrêts planifiés sont coûteux voire impossibles, c'est une fonctionnalité qui change concrètement les pratiques opérationnelles.

L'intégrer dans vos runbooks dès maintenant — en anticipant l'impact I/O et en préparant vos métriques de surveillance — vous permettra d'activer cette protection d'intégrité sans stress le jour où PostgreSQL 19 sera disponible en stable.

Suivez l'avancement de cette fonctionnalité sur le blog de depesz et dans les release notes officielles de PostgreSQL 19.