Florent Jardin   À propos  Archives

Dessine-moi un arbre (abstrait)

L’étape d’analyse crée un arbre d’analyse qui n’utilise que les règles fixes de la structure syntaxique de SQL. Il ne fait aucune recherche dans les catalogues système. Il n’y a donc aucune possibilité de comprendre la sémantique détaillée des opérations demandées.

(Documentation : Processus de transformation)

Que se passe-t-il entre l’instant où une requête SQL est soumise par l’utilisateur et l’envoi du résultat sous forme de lignes par le serveur PostgreSQL ? Cette question passionnante (pour une poignée de personnes, ne nous le cachons pas) a été étudiée par Stefan Simkovics durant sa thèse pour l’université de technologie de Vienne en 1998.

Ces travaux ont notamment permis d’enrichir la documentation officielle avec le chapitre « Présentation des mécanismes internes de PostgreSQL », qui reprend assez largement les observations de Simkovics de manière simplifiée pour en faciliter l’accès au plus grand nombre.

Dans cet article, je souhaite présenter de récentes découvertes sur l’une de ces phases internes, l’étape d’analyse, qui permet de manipuler une requête SQL sous une forme d’arbre et qui respecte un pattern de développement avancé nommé AST (abstract syntax tree).

» Lire la suite

Halte aux régressions

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 !

» Lire la suite

Conversions implicites

À 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.

» Lire la suite

Migrer vers PostgreSQL

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.

» Lire la suite

Les corruptions silencieuses

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.

» Lire la suite