Pour garantir la qualité du code d’un logiciel, rien de mieux que la validation
par les tests. Ces derniers peuvent être de différentes natures (fonctionnels,
intégration, unitaires, performance, etc.) et permettent de respecter une série
d’exigences que s’imposent les développeurs pour maintenir et faire évoluer ledit
logiciel dans la bonne direction.
Dans cet article, je souhaite explorer le système de tests tel qu’il est (et
a été) implémenté dans PostgreSQL et comment le réemployer dans la rédaction d’une
extension communautaire. Si vous ne connaissiez pas l’outil pg_regress, il
n’aura plus de secret pour vous !
À l’image d’un langage de programmation classique, le SQL manipule des données
typées, comme les chaînes de caractères, les dates ou des entiers numériques.
Les opérations de transformations ou de comparaison diffèrent en fonction du
type de données ; il ne sera pas possible de comparer le caractère A avec le
chiffre 4 mais l’opérateur || permettra la concaténation des deux éléments.
Dans cet article, je souhaite partager quelques anecdotes et problématiques de
terrain concernant cette particularité logicielle et comprendre les effets de
bord pour mieux les appréhender. Je prendrais un exemple assez spécifique du type
oid et d’un risque de transtypage pouvant perturber le stockage de Large
Objects dans une table, voire leur destruction non désirée.
Le marché de la migration en France est intense. Le Groupe de Travail
Inter-Entreprises PostgreSQL (PGGTIE) a même publié un guide de transition
à PostgreSQL à destination des entreprises françaises. Ce dernier est le fruit
de près de cinq années de travaux au sein de plusieurs organismes publics et a
pour ambition de démontrer l’intérêt de PostgreSQL aux décideurs techniques en
présentant les forces et les faiblesses du moteur.
Le mois dernier, une traduction en anglais est sortie des cartons pour
promouvoir davantage ce mouvement vers le logiciel libre dans les autres pays.
Je trouvais intéressant de profiter de cette actualité pour partager mes
réflexions du moment, entre ma vision du marché français et l’approche technique
pour engager les migrations de données vers PostgreSQL.
Parmi les drames universellement reconnus, les corruptions de données sont des
événements mécaniques ou logiques qui surviennent à des moments imprévisibles.
Tantôt il s’agira de l’âge avancé des secteurs disques, tantôt il s’agira d’une
extinction inopinée d’un composant électrique ou d’une perte de paquet dans les
protocoles de cache.
Bien que peu de personnes peuvent se vanter d’en avoir observé au cours de leur
carrière, les corruptions sont particulièrement dévastatrices lorsqu’elles se
sont propagées sur les supports de sauvegardes et détectées bien des jours, voire
des semaines après l’incident. Les moteurs de bases de données sont très résilients
face à ces destructions de données, en proposant des mécanismes de journalisation
adaptés. Malgré cela, des précautions sont de mises.
Jusqu’à très récemment, je ne me préoccupais pas de la pertinence de mes
sauvegardes de fichiers personnels réalisées naïvement avec un script rsync.
C’est honteux dans nos métiers, mais l’adage du cordonnier s’est vérifié avec
moi lors de l’exécution d’un vulgaire find $NOVAR/ -delete durant des tests.
Après cet épisode et l’amertume d’avoir perdu quelques travaux, ou la surprise
de découvrir les ravages de leur disparition plusieurs semaines après ma fatale
erreur, je me suis tourné vers l’outil incontournable dont tous mes collègues me
parlaient : BorgBackup