Nantes, le 25 mars 2021
Dalibo est spécialisé dans le support de PostgreSQL depuis 2005. Après tant d’années, cette activité nous a apporté un petit lot de contributions directes à PostgreSQL. Petite plongée dans le fonctionnement de notre support, notre quotidien, comment les problèmes liés au core de PostgreSQL sont pris en charge, et notre implication communautaire au travers de quelques expériences réelles.
Celui qui voulait annuler sa tâche
Au cours d’un ticket quasi estival de juin 2010, nous convenons avec l’un de nos clients de créer un nouveau tablespace et d’y déplacer une table.
La table ne contient que des données archivées, elle n’est pas utilisée, sa taille n’est que de 5 Go. L’opération peut donc se faire à chaud et ne devrait durer que quelques minutes tout au plus. Le client valide, tout le monde est sur le pont, la procédure est en place, le top départ est donné à 15h30.
Douze minutes après, la commande n’est toujours pas terminée. Pire, au vu de la vitesse de transfert (environ 3 Mo/s), les meilleures estimations requièrent 20 minutes supplémentaires. C’est alors que le responsable applicatif appelle : les utilisateurs n’arrivent plus à travailler depuis 10 minutes, la production est totalement ralentie, presque à l’arrêt !
Décision est prise d’interrompre la maintenance. Nous lançons plusieurs tentatives d’annulation de la commande. Sans effet. Il n’est pas souhaité, ni souhaitable, que cette commande soit interrompue brutalement. Tout le monde prend alors son mal en patience et comme prévu, la commande se termine vers 16h.
Le jour-même, nous envoyons un patch sur la mailing list de développement de notre SGBD préféré.
S’ensuit un court échange et un petit silence radio communautaire. Le patch est finalement accepté et intégré 10 jours après avoir été proposé. Il aura été simple et rapide à produire grâce à l’organisation et la qualité du code de PostgreSQL (et au talent de son auteur bien entendu). Il n’a qu’une seule ligne de code effective : CHECK_FOR_INTERRUPTS();. Plus d’informations ici.
Ceux qui étaient en conférence
Nous sommes en octobre 2019. Quelques personnes de Dalibo sont à Milan en Italie pour participer aux pgconf.eu.
Dans le même temps, nous travaillions depuis plusieurs jours avec l’un de nos clients sur une procédure de mise à jour majeure reposant sur la réplication logique. Plusieurs petits problèmes s’étaient accumulés dans cette procédure atypique que nous corrigions étape par étape.
Étant donné la volumétrie concernée, les tests et validations étaient longs, des timeouts étaient signalés par le wal_sender, certaines erreurs rencontrées nécessitaient un temps d’investigation important et pouvaient mettre en cause le comportement de la réplication logique. Décision avait alors été prise de faire grimper le ticket à la catégorie 4.
Lorsque la catégorie 4 est atteinte, l’équipe technique est la même, mais des consultants supplémentaires sont conviés à participer au ticket. Nous plongeons dans le code de PostgreSQL pour expliquer certains comportements, ou pour remonter à la source d’un bug.
Lors de l’analyse des logs, nous découvrons que le paramètre wal_receiver_timeout ne semble pas respecté. Un scénario est produit afin d’isoler ce cas à part. Nous sommes alors le 17 octobre, en pleine conférence.
Notre consultant s’installe alors au « hacker lounge » pour poursuivre son analyse. Il y retrouve alors un vieux compagnon, Julien Rouhaud (actuellement chez VMware). Ils s’installent tous les deux, commencent à échanger autour du problème, Julien attire l’attention de Nick Babadzhanian (actuellement chez Adjust). Ils discutent, plaisantent, analysent ensemble, Julien distribue les points et bons conseils. Il finira par proposer un patch qui déplace une unique ligne d’un bloc de code à son parent.
Le mail est envoyé le 17 octobre 2019 à 18:00 UTC, 20h en Italie.
Le patch est relu et intégré dans toutes les versions maintenues de PostgreSQL moins de 12 heures plus tard, depuis le Japon, mais au petit matin pour l’Italie !
L’escalade en interne, l’analyse puis la reproduction en amont ont permis de rapidement présenter le problème sur un coin de table. L’exercice aura occupé moins d’une heure de trois personnes provenant de trois entreprises différentes, dans le cadre convivial de PostgreSQL Conference Europe. Une saine émulation et coopération communautaire !
Celui qui relance le train
Toujours dans le cadre du même ticket concernant la réplication logique, nous poursuivions nos efforts autour de cette procédure incluant des étapes inattendues et qui faisaient apparaître un autre message étrange :
ERROR: negative bitmapset member not allowed
Ce message d’erreur est adressé aux développeurs, il n’est pas destiné à apparaître en production. Un bug s’est donc glissé quelque part. Par ailleurs, ce message d’erreur avait déjà été déclaré en avril 2019, dans un contexte similaire, mais faute de scénario de reproduction, il n’avait pu être analysé et corrigé. Le train était arrêté au milieu des voies.
Or, grâce cette procédure atypique que nous avions en main, nous avions de quoi remettre une bûche dans la chaudière. Nous avons construit un scénario de reproduction et sommes montés à bord de cette ancienne conversation. S’ensuivit l’analyse détaillée pour remonter aux racines du bug lors du voyage retour de Milan, ce qui a permis de proposer une explication et un correctif. Le train avait repris son rythme de croisière le 25 octobre !
Quelques court échanges ont permis à Peter Eisentraut et Andres Freund d’alléger le scénario avant de l’ajouter aux tests de non régression de PostgreSQL, puis d’intégrer le patch officiellement. Nous sommes alors le 9 novembre 2019.
Ce cas nous permet de souligner, plus fortement encore, l’importance d’avoir un scénario permettant de reproduire un bug. Sans exemple concret, il est extrêmement compliqué, voire impossible pour les développeurs de pouvoir identifier l’origine d’un bug. Si vous pensez avoir trouvé un bug, collectez toutes les informations possibles à la reproduction de celui-ci, et préparez un jeu de tests pour reproduire le problème.
Celui dont le plan se déroule avec accrocs
Il arrive parfois que nos propres collègues sollicitent du support en interne. Ce ticket en est l’exemple, déclaré le 16 juillet 2020.
Dans ce cas particulier, l’excellent PEV2 nous présente un plan où la requête traite un nombre négatif de blocs en mémoire. Étrange. L’auteur du projet identifie très rapidement une anomalie dans le plan qui fait ricochet et grippe la belle interface de PEV2. Il diffuse alors le lien sur les canaux interne de Dalibo et comme d’habitude, le premier réflexe est de reproduire le bug, puis d’en chercher la solution.
Deux jours plus tard, une proposition de correctif est envoyée. Après quelques échanges, le patch est intégré le 25 juillet 2020.
Le support n’est donc pas notre seule source d’inspiration pour contribuer activement au code source de PostgreSQL et modestement à sa qualité !
Conclusion
Nous avons encore quelques autres histoires similaires, mais la qualité de PostgreSQL étant ce qu’elle est, il faut bien admettre que nous avons rarement l’occasion de traiter des bugs.
Nous avons choisi ces quatre sujets car ils illustrent comment nous découvrons ou prenons en charge un bug, comment ce dernier escalade au sein des équipes, comment il est analysé et comment la communauté fonctionne en retour. Quel que soit le degré de complexité du bug, la procédure est la même :
- prendre le temps nécessaire à produire un rapport de bug aussi détaillé et reproductible que possible à la communauté. Cette étape est parfois plus longue que la résolution elle-même !
- analyser le bug et son origine ;
- tenter de proposer un correctif ;
- maintenir le lien avec la communauté, être réactifs, disponibles et conserver le sujet actif.
Pour finir, dans la grande tradition de la communauté PostgreSQL, vous constaterez que les échanges sont toujours de très bonne qualité, rapides et totalement transparents. Le projet PostgreSQL démontre parfaitement les multiples intérêts des logiciels libres pour les professionnels et l’intérêt d’en soutenir le développement au travers d’un support spécialisé.
Des questions, des remarques ?
Écrivez-nous à contact@dalibo.com
