Fiabilité du stockage des données avec PostgreSQL

[Phil]

Merci à un RSI pour sa question :

"J'ai lu que PostgreSQL avait un problème grave dans le stockage des données depuis 20 ans. Cela ne sonne pas très pro, pouvez-vous expliquer ?"

Réponse :

Vous évoquez sans doute la surprise fsync, information reprise notamment dans cet article francophone https://www.developpez.com/actu/245794/ ... SDEM-2019/
PostgreSQL s'appuie sur les couches inférieures, elles doivent être fiables mais c'est au final le cas quel que soit le SGBD. Si votre système de stockage est corrompu, que vous ne sauvegardez pas etc. alors il y aura tôt ou tard perte de données.
Ici, le problème était que la corruption pouvait être silencieuse. Cependant, les cas réels correspondant au cas théorique sont extrêmement rares. C'est la raison pour laquelle ce problème, monté en épingle par certains, n'a pas été détecté plus tôt.
Un appel à fsync() est censé rendre persistante une écriture. Après un premier échec matériel, supprimer les données des pages affectées et les marquer simplement comme étant propres n'est à mon sens PAS un comportement adéquat. C'est peut-être cohérent pour gérer une clé USB retirée d'une station de travail mais pas pour un OS serveur. Cela révèle beaucoup plus de choses sur le noyau Linux que sur PostgreSQL. Il est à noter que FreeBSD n'a par exemple pas ce comportement.
La communauté PostgreSQL a éliminé le risque pour toutes les versions supportées dans les versions mineures sorties en février 2019 (9.4.21, 9.5.16, 9.6.12, 10.7, 11.2) et ce problème ne peut plus survenir. Au premier échec du fsync, PostgreSQL sortira en PANIC.
Si vous travaillez avec un OS ne présentant pas ce comportement pour fsync, par exemple FreeBSD, il est toujours possible de revenir au comportement précédent (retenter le fsync) via un paramètre, data_sync_retry.