Postgresql 8.3 - commit asynchrone

Postgresql 8.3 vient de sortir, et voilà une release qu'elle est excitante! Parmi la multitude de nouvelles fonctionnalités, notons plus particulièrement le commit asynchrone, qui devrait être particulièrement intéressant pour Adh.

Lorsque l'on modifie des données dans la base, le système ne retourne du commit que lorsque les données ont été effectivement écrites sur le disque, dans le wal (write ahead log). Ainsi, on a la garantie que s'il y a une coupure de courant, à partir du moment où le commit a été fait, nous n'avons rien perdu.

Bien sûr, cette garantie a un coût, puisqu'il va falloir accéder au disque. Mais par exemple dans un système financier, où il est hors de question de perdre la moindre transaction, cette fonctionnalité est d'une importance capitale.

Il existe cependant une option qui permet de se passer du wal, et de faire des commit en mémoire, l'information étant écrite sur le disque après coup. Autant ceci améliore grandement les performances, autant c'est plutôt dangereux pour des donnés sensibles. En effet, s'il y a coupure de courant, non seulement on ne sait pas quelles sont les transactions qui ont été effectivement écrites sur le disque, mais la base pourrait contenir des données corrompues! On ne peut donc utiliser ce mode que lorsque l'on a besoin de hautes performances, mais que les données en elles-mêmes ne sont pas capitales, par exemple pour enregistrer des données issues de capteurs durant une simulation. Si l'on perd la base, on la reconstruit, on réimplante la dernière sauvegarde, et on relance la simulation!

Le commit asynchrone de postgresql 8.3 propose une fonctionnalité intermédiaire, qui est de permettre de revenir du commit avant que les données soient sur le disque, mais garantit que s'il y a coupure, la base reste dans un état propre, ne perdant que les transactions qui ont été exécutées dans les derniers instants.

Adh peut bénéficier grandement de ce mode. En effet, en cas de coupure, un joueur qui par exemple commerce avec un autre en sera quitte pour recommencer sa négociation, sans risquer que l'argent soit parti mais l'objet jamais arrivé. Quelques secondes de perdue en cas de panne sont parfaitement acceptables si elles permettent d'améliorer la vitesse du jeu.