PostgreSQL PANIC : quand votre base de données crie au secours (et a raison)

Un matin, votre monitoring s'emballe. PostgreSQL a émis un PANIC et redémarre. Premier réflexe : c'est un bug Postgres. Mauvaise piste. Certaines des pannes les plus sévères que la communauté ait documentées ne venaient pas du moteur lui-même, mais de la couche en dessous : le noyau Linux, la glibc, l'allocateur de pages.

Cet article s'appuie sur la série Postgres War Stories de Payal Singh (source originale) pour décortiquer le cas le plus emblématique : le fsyncgate de 2018. Un incident qui a redéfini la façon dont PostgreSQL interagit avec le système de fichiers, et qui justifie aujourd'hui un paramètre que beaucoup d'équipes laissent à sa valeur par défaut sans en comprendre les enjeux.

Le fsyncgate : quand Linux mentait à PostgreSQL

Pendant des années, PostgreSQL a fonctionné sur une hypothèse raisonnable :

• fsync() retourne succès → les données sont sur le disque.
• fsync() retourne erreur → on peut retenter l'opération.

Linux ne respectait ni l'un ni l'autre de ces contrats dans certaines conditions.

Sous certains systèmes de fichiers, lors d'erreurs d'écriture différée (writeback errors), le noyau effaçait l'erreur après que le premier processus l'ait lue. Le prochain appel fsync() retournait donc succès... alors que des pages mémoire étaient toujours dirty et n'avaient jamais atteint le disque physique.

Conséquence concrète : PostgreSQL croyait avoir persisté des données qui n'existaient en réalité que dans le cache mémoire du noyau. En cas de crash ou de coupure d'alimentation, ces données disparaissaient silencieusement. Aucune erreur dans les logs. Aucun signal d'alarme. Juste de la corruption de données.

C'est ce scénario catastrophe, révélé publiquement en 2018, qui a été baptisé fsyncgate.

La réponse de PostgreSQL : le PANIC volontaire

Face à cette trahison du système d'exploitation, l'équipe de développement de PostgreSQL a fait un choix radical à partir de la version 11 : en cas d'échec de fsync(), PostgreSQL déclenche délibérément un PANIC.

Pourquoi un PANIC plutôt qu'une tentative de récupération ?

Parce que si l'OS ne peut plus garantir l'intégrité des écritures, continuer à fonctionner serait plus dangereux qu'arrêter. Le PANIC force un redémarrage et une récupération depuis le WAL (Write-Ahead Log), le journal de transactions de PostgreSQL. C'est douloureux opérationnellement, mais c'est la seule garantie que les données restent cohérentes.

Un PANIC PostgreSQL sur fsync() n'est pas un bug. C'est un mécanisme de protection de l'intégrité de vos données.

Le paramètre clé à connaître est data_sync_retry. Sa valeur par défaut depuis PG 11 est off, ce qui signifie : ne jamais retenter un fsync() en erreur, déclencher un PANIC à la place. Laissez-le à off. Le passer à on revient à réactiver le comportement pré-fsyncgate et à s'exposer aux mêmes risques de corruption silencieuse.

Ce que ça change pour les équipes ops et les développeurs

🔍 Migrez si vous êtes sous PG 10 ou antérieur

Les versions antérieures à PostgreSQL 11 ne disposent pas du comportement protecteur. Il n'existe pas de patch rétroactif ni de contournement propre. Si votre infrastructure tourne encore sur PG 9.x ou 10, la migration vers PG 11+ n'est pas optionnelle — c'est une question d'intégrité des données.

📋 Ajoutez les PANIC à votre runbook

Les événements PANIC dans les logs PostgreSQL sont rares par nature. Quand ils apparaissent, ils signalent quelque chose de sérieux. Configurez vos outils de monitoring (Datadog, Prometheus + Alertmanager, CloudWatch Logs Insights...) pour alerter immédiatement sur les patterns suivants dans les logs :

PANIC: could not write to file
PANIC: fsync failed

Dans votre runbook, documentez explicitement :

1. Un PANIC sur fsync() n'est pas un bug PostgreSQL à reporter.
2. Vérifiez l'état du système de fichiers et des disques sous-jacents (dmesg, smartctl, logs du stockage réseau si applicable).
3. Laissez PostgreSQL terminer sa recovery depuis le WAL — n'intervenez pas manuellement sur les fichiers de données.

⚙️ Vérifiez votre configuration

Un audit rapide sur toute instance PG 11+ :

SHOW data_sync_retry;
-- Résultat attendu : off

Si vous trouvez on, c'est une dette technique à traiter.

La leçon systémique : PostgreSQL ne peut protéger que ce que l'OS lui dit

Le fsyncgate illustre une vérité souvent oubliée en production : un moteur de base de données est aussi fiable que la pile sur laquelle il repose. PostgreSQL peut implémenter le WAL le plus robuste du monde — si le noyau Linux lui ment sur l'état des écritures disque, le moteur est aveugle.

Cette réalité doit influencer vos décisions d'infrastructure :

• Les systèmes de fichiers ont des comportements différents face aux erreurs d'I/O. ext4, XFS, ZFS ne gèrent pas tous les writeback errors de la même façon.
• Le stockage en réseau (NFS, SAN, EBS AWS) ajoute des couches supplémentaires où des erreurs peuvent être masquées ou retardées.
• Les environnements virtualisés peuvent introduire des latences d'I/O qui amplifient ces problèmes.

La bonne pratique n'est pas de faire confiance à chaque couche, mais de s'assurer que les échecs remontent jusqu'à un niveau où ils peuvent être traités — c'est exactement ce que fait le PANIC de PostgreSQL 11+.

Conclusion

Le PANIC PostgreSQL sur une erreur fsync() est contre-intuitif : une base de données qui s'arrête volontairement semble moins fiable. C'est l'inverse. C'est la preuve qu'elle refuse de vous mentir sur l'état de vos données.

Les actions concrètes à mener dès cette semaine :

1. Vérifier la version PostgreSQL de chaque cluster en production. PG 11 minimum.
2. Contrôler data_sync_retry — il doit être à off.
3. Ajouter une alerte sur les PANIC dans votre stack de monitoring.
4. Documenter le comportement attendu dans votre runbook pour que l'équipe d'astreinte sache ne pas paniquer quand PostgreSQL, lui, décide de le faire.

La fiabilité d'une base de données en production se construit autant dans le runbook et le monitoring que dans le code applicatif.

Cet article est inspiré de la série Postgres War Stories de Payal Singh, une excellente ressource pour les équipes opérant PostgreSQL à grande échelle.