gleu's blog

Je m'implique de plus en plus dans le projet pgAdmin. Auparavant, je faisais de petits patchs ou de la traduction. Maintenant, et notamment avec mon envie de revoir l'intégralité des dialogues de propriétés, je dois aller un peu plus loin. En effet, lorsque je modifie le contenu d'un dialogue, je vérifie sur Linux ce que ça donne. Et j'envoie un patch quand le résultat me satisfait. Malheureusement, sur Windows, comme sur Mac, le résultat n'est pas forcément aussi bon. Il faut donc vérifier l'affichage sur toutes les plateformes. Je ne peux pas demander à Dave Page (le développeur principal, qui dispose de quoi vérifier sur toutes les plateformes officiellement supportées) de tester chacune de mes modifs. Surtout que, quand il trouve un problème spécifique à une plateforme que je n'ai pas, c'est galère à déboguer.

Donc, il me fallait avoir la possibilité de tester sur les trois plateformes : Linux, Windows et Mac.

Pour Windows, c'est simple : une machine virtuelle et hop, c'est parti. Bon, dans les faits, c'est pas si simple. Il faut installer Visual Studio Express, compiler wxWidgets, compiler pgAdmin... que des emmerdes représentant plusieurs heures de boulot (dans le sens plusieurs jours d'affilée). Mais bon, ça se fait. Difficilement, mais on y arrive.

Pour Mac, c'est autre chose. Il faut déjà acheter une machine Apple. J'ai opté sur les conseils de Dave pour un Mac Mini de base. Bref, acheté jeudi, installé vendredi, compilation de pgAdmin le samedi matin. Beaucoup plus cher (à cause de l'achat de la machine) mais beaucoup plus facile à compiler/installer/tester. En deux/trois heures, c'était prêt.

Bref, voilà. Je peux générer une version Linux, Mac et Windows de pgAdmin, ce qui devrait améliorer mon travail et aussi l'accélérer.

Bon, c'est pas un patch du moteur... mais quand même, ça me fait bêtement plaisir

Lorsque vous utilisez l'outil client psql avec un serveur PostgreSQL de version antérieure, les métacommandes (\du par exemple) pouvaient vous renvoyer une erreur. Par exemple :

 guillaume@laptop:~$ psql -tc "select version()" aa
  PostgreSQL 8.0.17 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

 guillaume@laptop:~$ /opt/postgresql-8.3/bin/psql --version
 psql (PostgreSQL) 8.3.3
 contains support for command-line editing
 guillaume@laptop:~$ /opt/postgresql-8.3/bin/psql aa
 Welcome to psql 8.3.3 (server 8.0.17), the PostgreSQL interactive terminal.

 Type:  \copyright for distribution terms
        \h for help with SQL commands
        \? for help with psql commands
        \g or terminate with semicolon to execute query
        \q to quit

 WARNING:  You are connected to a server with major version 8.0,
 but your psql client is major version 8.3.  Some backslash commands,
 such as \d, might not work properly.

 aa=# \du
 ERROR:  relation "pg_catalog.pg_roles" does not exist
 ERROR:  relation "pg_catalog.pg_roles" does not exist

Ce que mon patch fait, c'est de modifier dynamiquement la requête exécutée suivant la version du serveur où psql est connecté :

 guillaume@laptop:~$ /opt/postgresql-head/bin/psql aa
 psql (8.4devel, server 8.0.17)
 WARNING: psql version 8.4, server version 8.0.
          Some psql features might not work.
 Type "help" for help.

 aa=# \du
            List of roles
  Role name | Attributes | Member of
 -++-
  guillaume | Superuser  |
            : Create DB
  postgres  | Superuser  |
            : Create DB
  pouet     |            |

Voilà, c'est pas grand chose, mais c'est plaisant Je pense que je vais travailler sur un autre patch pour le prochain commit fest.

Les RMLL 2008 ont commencé mardi dernier. PostgreSQLfr est présent : un stand, une conférence, six ateliers. Autant dire que cette année, on a assuré.

L'organisation me semble meilleure que les années précédentes. Inscription et enregistrement rapides, wifi fonctionnel (en dehors de quelques déconnexions), salles propres et bien équipées. Bref, excellent.

Concernant uniquement la partie PostgreSQL... le premier jour, j'ai fait ma présentation de PostgreSQL. Cela s'est bien passé. J'avais une vingtaine de personnes qui sont restées même au-delà du temps déjà allongé (normalement 45 minutes pour une conf, j'avais obtenu exceptionnellement 1h30... et j'ai réussi à les tenir deux heures). Apparemment, ils étaient content de ma presta. Aujourd'hui, j'ai commencé le bal des ateliers avec « Installation de PostgreSQL » (Thomas était prévu mais, pour des raisons personnelles, a dû se décommander). Une dizaine de personnes qui ont bien suivi les différentes étapes de l'installation d'un serveur. Cet après-midi, ce fut au tour de Sébastien Lardière qui a présenté Slony. Environ sept personnes pour cette présentation, qui s'est là-aussi bien déroulée. Quant au stand, c'est un peu moins la fête. Sur les deux jours, nous avons dû avoir seulement une petite vingtaine de visiteurs. Autant dire que c'est décevant. Cependant, pour ce que j'en vois, je n'ai pas l'impression que les autres stands soient mieux lotis que nous. Peut-être que le grand espace alloué aux associations fait que je me trompe. Quand même, c'est pas la foule. Je ne serais pas étonné d'apprendre que le nombre de visiteurs est moins important que l'année dernière.

Voilà. Si vous êtes dans le coin, n'hésitez pas à passer, nous serons là jusqu'à la fin. On a notamment encore quatre ateliers (écriture de procédures stockées, recherche plein texte, réplication avec bucardo, pitr et log shipping).

Ça faisait un petit moment que je n'avais pas bossé sur pgAdmin. J'ai profité de l'après-midi et la soirée du samedi pour bosser sur plusieurs patchs :

• raccourcis des menus contextuels mal affichés ;
• activation du champ SQL dans les fenêtres de propriétés ;
• utilisation du dialogue de couleurs pour la fenêtre de propriété du serveur ;
• séparation du champ commentaire dans son propre onglet.

Raccourcis

Depuis un petit moment, les menus contextuels de pgAdmin s'affichaient mal. Au lieu d'avoir la lettre du raccourci soulignée, j'avais un tiret bas devant la lettre :

Je pensais que c'était de ma faute (mauvaise compilation, mauvaise configuration, etc). Un mail sur pgadmin-support m'a indiqué que je n'étais pas le seul. Après une discussion avec Dave et quelques tests, je me suis aperçu que la version 2.8.5 de wxWidgets semblait être la coupable. À force de recherche, j'ai fini par retrouver le commit responsable du problème sur le SVN de wxWidgets. Au prix d'une longue conversation, j'ai même réussi à convaincre les développeurs de wxWidgets de la présence de ce bug. La correction est apparue hier soir sur leur dépôt (branche WX_2_8_BRANCH). La version 2.8.8, contenant ce correctif, devrait bientôt sortir.

Ajout du dialogue de couleur

Lors de pgcon2008, Dave a intégré un patch qui permet d'ajouter une couleur de fond pour chaque serveur sur le navigateur d'objets :

Bon, je ne trouve pas que ce soit super beau, mais ce qui m'a surtout gêné, c'est l'interface utilisateur pour saisir la couleur. Un utilisateur doit saisir le code couleur sous la forme d'une couleur HTML. C'est juste un bête champ texte. J'en ai donc profité pour ajouter un bouton :

et j'ai fait en sorte que le clic sur ce bouton affiche la fenêtre standard de saisie d'une couleur :

Ce patch a été accepté, il est enregistré dans le SVN depuis hier soir.

Activation du champ SQL

Jusqu'à la version 1.8, l'onglet SQL ne permet pas de modifier le champ contenant la requête SQL. En cas d'erreur de pgAdmin pour la génération du SQL permettant d'appliquer les modifications de l'utilisateur sur l'interface, je pense qu'il faut avoir un moyen pour que l'utilisateur modifie le SQL généré par pgAdmin. Le meilleur exemple est lorsqu'on ajoute une colonne avec une contrainte NOT NULL. Sans plus d'informations, la requête échouera car la nouvelle colonne n'aura aucune valeur et ne pourra pas se voir ajouter la contrainte NOT NULL. IL faut donc que l'utilisateur puisse ajouter le code SQL permettant l'ajout d'une valeur par défaut aux lignes déjà présentes.

Mon patch ajoute une case à cocher permettant d'autoriser la modification du champ SQL. Comme Dave et moi ne voulons pas gérer le reverse engineering des modifications apportées dans le champ SQL, tous les objets des autres onglets sont désactivés. On peut voir le contenu des onglets, mais pas le modifier.

J'ai parlé d'un champ texte pour la requête SQL. J'aurais plutôt dû parler de deux champs car il y a deux groupes de requêtes. En effet, deux objets peuvent avoir besoin de deux transactions de modification : les bases de données et les tablespaces. Ceci est dû à une correction sur la version 8.3 de PostgreSQL.

Voici donc le résultat :

Dernier problème à régler : si un utilisateur modifie le nom de l'objet créé dans la requête, le navigateur d'objet affiche toujours le nom indiqué dans le champ texte Nom, et pas celui modifié. Après un rafraichissement, tout va bien... mais en attendant, l'affichage est faux. Donc, il me reste du boulot sur celui-ci.

Séparation du champ commentaire

L'idée de ce patch était de déplacer le champ Commentaire dans un autre onglet car certains dialogues deviennent vraiment trop longs. Sur mon portable, je n'ai plus accès au tiers du dialogue de création/modification d'une table (ce qui est gênant pour cliquer sur le bouton OK). Aucune technicité requise pour ce patch, juste cinq heures à passer à créer le nouvel onglet, à déplacer le texte statique et le champ texte dans ce nouvel onglet, et à revoir les placements de contrôles, pour chaque dialogue sur les propriétés des objets. Je ne sais pas comment, j'ai perdu la moitié de mon patch. Cependant, Dave est plutôt contre pour au moins deux bonnes raisons :

• deux dialogues ont un grand nombre d'onglets, ce qui rend leur gestion plus douloureuse qu'autre chose ;
• il existait une règle sur la création de dialogues, règle que je ne connaissais (car planqué dans une ancienne branche, et oublié depuis là-bas)... Dave l'a d'ailleurs ajouté à la page Wiki sur le développement de pgAdmin.

Bref, patch abandonné.

Conclusion

/me content

La plupart de mes travaux de samedi dernier ont donné un résultat direct, soit sur wxWidgets soit sur pgAdmin. J'ai encore plein d'idées à mettre en place. J'ai d'ailleurs envoyé deux mails pour parler de deux gros projets :

• le premier est de revoir les dialogues pour qu'ils soient facilement redimensionnables... ajouter un onglet n'améliore évidemment pas la situation ;
• le second concerne la fenêtre d'état du serveur.

Du boulot en prévision

La nouvelle a fait grand bruit sur la liste pgsql-hackers. Tom Lane a annoncé le 29 mai 2008 que la « core team » veut ajouter la réplication directement dans le moteur de PostgreSQL. Évidemment, cela change du discours habituel (« no "one size fits all" replication solution »). En fait, ce changement est survenu après la conférence d'Andrew lors de pgcon 2008. Les développeurs PostgreSQL attendaient un retour des développeurs de modules de réplication. Ce retour ne venant pas, ils ont décidé d'intégrer une solution de réplication dans PostgreSQL. Le but n'est évidemment pas d'empêcher l'existence des autres solutions, mais d'en proposer une par défaut et facile à installer.

Il existe déjà un bout de réplication dans PostgreSQL. Il est possible de faire envoyer les journaux de transactions sur un deuxième serveur et de faire en sorte que ce serveur restaure en continue les données contenues dans les journaux de transactions. Donc, on se retrouve avec un deuxième serveur, en restauration continue, prêt à prendre la main en cas de problème sur le serveur principal. C'est ce qu'on appelle le « Warm Standby » ou encore « Log Shipping ». Néanmoins, la solution n'est pas parfaite :

• vous devez répliquer l'instance complète (pas de choix des objets à répliquer comme avec Slony par exemple) ;
• l'esclave n'est pas disponible (alors qu'il est en lecture seule sur la plupart des autres outils de réplication, Slony par exemple) ;
• vous pouvez perdre l'équivalent en données d'un journal de transaction (à modérer avec le paramètre « archive_timeout » qui permet justement d'avoir un délai maximum avant de forcer l'utilisation d'un nouveau journal de transaction... ce qui a un prix en terme de bande passante, surtout si votre esclave dépend d'une ligne peu rapide) ;
• la réplication est asynchrone (ce qui peut-être parfaitement acceptable dans certains cas et intolérable dans d'autres).

Le but est de répondre aux deux derniers points pour offrir une réplication, asynchrone et/ou synchrone, sans délai. Pour cela, il faut bien comprendre ce qu'est un journal de transactions. Un journal est une aggrégation de pages disques qui ont été modifiées. Il contient aussi d'autres types d'enregistrement comme les CHECKPOINT, mais il est principalement composé de pages disques. Chacune de ces pages disques (de 8 Ko) représente une modification sur une partie d'un fichier représentant une table ou un index. Plutôt que d'envoyer ces pages disques regroupées en bloc de 16 Mo (donc au maximum 2048 pages disques stockées), les développeurs de PostgreSQL voudraient les envoyer grouper par transaction. En effet, suivant la transaction SQL exécutée, une ou plusieurs pages disques seront ajoutées au journal de transaction pour indiquer les modifications entreprises. Plutôt que d'envoyer un journal de transaction (qui peut contenir des transactions validées et/ou annulées, plusieurs transactions ou une partie d'une transaction), il est préférable de récupérer toutes celles qui correspondent à une transaction et à envoyer tout d'un coup après COMMIT et/ou ROLLBACK. De cette façon, la réplication est en temps réel.

La question du type de réplication s'est aussi posée : sera-t-elle asynchrone (comme le LogShipping ou comme Slony) ou synchrone (comme... euh... bin, rien que je connaisse pour être franc) ? et la réponse de Tom Lane n'a pas tardé : « les deux, suivant la configuration ». Là aussi, c'est très bien joué. Plutôt que d'imposer le type de réplication, on laisse le choix à l'administrateur. Avoir une réplication synchrone n'est pas que du bonheur, ça a un impact sur les performances. Tous les esclaves devront renvoyer un message pour indiquer qu'ils ont bien reçu (et enregistré sur disque) la transaction avant que le serveur maître puisse dire au client que les données sont enregistrées. Donc, pour les cas où une réplication synchrone est inutile, la désactiver permettra de gagner en performances.

Il est prévu malgré tout de travailler sur l'utilisation des esclaves en lecture seule. Le travail reste important. D'après Simon Riggs, il sera difficile d'intégrer ça dans la version 8.4. Il est plus probable que l'on verra ça seulement en 8.5. Tout dépend en fait de la façon dont NTT va communiquer sur ce sujet. NTT est une entreprise asiatique qui a déjà développé ce type de réplication (avec un composant de haute-disponibilité utilisant Heartbeat). Eux-aussi ont réalisé une présentation de ces travaux lors de pgcon2008. Les slides permettent de bien comprendre leur travaux, ne surtout pas hésiter à les lire.

Pour terminer, ce que cette réplication ne fera pas :

• répliquer à un niveau plus fin que l'instance même.
• pas de possibilité de mettre à jour vers une nouvelle version majeure de PostgreSQL (je dis bien majeure, car les mineures seraient possibles d'après Simon Riggs).
• pas de failover automatique.

Voilà, un post un peu long sur une fonctionnalité très attendue et très prometteuse. La version 8.4 semble décidément très alléchante.

Ça y est, c'est officiel. L'association PostgreSQLfr.org sera présent en force pour les RMLL2008.

Il n'y aura malheureusement qu'une seule conférence sur PostgreSQL, une version légèrement améliorée et mise à jour de la conférence pour Parinux. Il y aura malgré tout six ateliers, animés par cinq intervenants différents : installation de PostgreSQL, réplication avec Slony, procédures stockées en PL/pgsql, PITR et LogShipping, réplication avec bucardo, utilisation de la recherche plein texte en 8.3. Et il y aura évidemment un stand. Que demande le peuple

Bref, tout est là et là.

Pour tout avouer, ça avait mal commencé. À cause d'un incendie à Gare du Nord, le RER B s'est déplacé super lentement, me faisant arriver avec un quart d'heure de retard. Néanmoins, on m'avait attendu. J'avoue que le nombre de personnes présentes m'a agréablement surpris. Avec ce grand pont, je m'attendais à ne pas avoir grand-monde. Il y avait quand même entre 20 et 25 personnes dans la salle qui, du coup, était remplie à ras bord... quelques personnes ont assisté aux 1h30 de conférence debout. Qu'ils soient tous remerciés d'être venus.

En dehors de mon retard, tout s'est bien passé. J'ai l'impression que la présentation correspondait à ce qu'ils attendaient. En fait, cette présentation est une refonte de ce qu'on appelle le module A à Dalibo. C'est un module qu'on ajoute dans toutes nos formations car il permet de mieux comprendre « PostgreSQL, le logiciel » et « PostgreSQL, la communauté » et à quel point l'un comme l'autre sont essentiels. Les slides sont disponibles sur ce billet, ainsi que sur le SVN de l'association pour qu'elle soit utilisable/modifiable par d'autres. Je l'ai même déjà modifié pour ajouter deux slides qui manquaient et la licence.

Parmi les présents, il y avait évidemment manu (président de Parinux) et Julia (celle qui a organisé la présentation). Qu'ils soient ici publiquement remerciés pour avoir rendu possible cette présentation. Il y avait aussi dup et toady, deux (anciens ?) Aldiliens. Ces deux-là, Sabine (trésorière de Parinux) et moi sommes partis dîner chez Mémère Paulette, super resto où on a super mangé évidemment . Toady nous a fait une démonstration de son Wolfotrack, un Wolfenstein 3D qui permet de killer des connexions réseau. Excellent. La bouffe était bonne, la soirée excellente. Que du bon. Je suis prêt à recommencer. Un LUG serait intéressé par une conf ?

Vendredi dernier, j'ai beaucoup « joué » avec Inkscape. Mon but principal était de créer l'équivalent des posters Oracle sur les tables DBA. J'ai donc créé un poster sur les catalogues statistiques de PostgreSQL (ça s'affiche très mal sous firefox Beta 5, faites plutôt un clic droit et « Sauvegarder sous » et affichez-le avec Inkscape).

Ensuite, j'ai travaillé à dessiner un schéma des catalogues PostgreSQL (là, par contre, ça s'affiche plutôt bien... mais que ça ne vous empêche pas de le sauvegarder pour le regarder avec Inkscape) et précisant les relations entre chaque catalogue. C'est un schéma qui est demandé de temps à autre sur les listes de discussion. C'est donc encore un TODO à barrer de ma liste

Tout commentaire bienvenu évidemment.

PS : Inkscape, c'est trop de la balle grave

Ça fait un petit moment que je cherche à terminer ma relecture complète des fichiers .po français du projet PostgreSQL. C'est tellement long que la démotivation régnait sur ce projet. Le problème est de relire des milliers de lignes (2847 rien que pour le plus gros, à savoir postgres.po), de modifier de mémoire pour obtenir les mêmes traductions sur les différentes versions. La mémoire pose problème dans ce cas car il est difficile de se rappeler la traduction d'une certaine phrase... manuellement, c'est mission impossible. Aligner les sorties des options est simple comparé à ce jeu de mémoire.

Dimanche dernier, je me suis rappelé qu'on m'avait parlé d'un système de mémoire gettext. En fait, l'idée est tout bête. Pour éviter de traduire plusieurs fois la même phrase, un outil gettext propose une traduction qu'il récupère d'un mémoire. J'avais auparavant aucune idée sur la façon de créer ce mémoire. Mais dimanche, une idée a subitement germé : la version 8.3 a été entièrement relue, ce fut long et fastidieux mais c'est fait. On peut donc se servir de ces traductions déjà vérifiées comme mémoire pour les autres versions.

J'ai donc commencé à chercher des outils pour m'aider en me disant que, dans le pire des cas, j'écrirais ces outils. Comme d'habitude, pas besoin, les outils existent déjà. Donc voici un petit résumé...

msgen permet la création d'une mémoire gettext. Avec ces commandes, j'ai créé un sous répertoire contenant le mémoire pour chaque .po particulier de PostgreSQL:

cd head
mkdir ../memoire
for fichier in *.po
do
  LANG=C msgen -o ../memoire/${fichier}t $fichier
done

Ensuite, il a fallu combiner la mémoire des traductions de la dernière version (la 8.3) avec les traductions des versions précédentes. Cet assemblage nécessite l'outil msgmerge :

for fichier in *.po
do
 mv $fichier ${fichier}.bak
 echo -n "$fichier "
 LANG=C msgmerge --no-wrap -N -o $fichier ../memoire/${fichier}t ${fichier}.bak
done

L'option --no-wrap empêche msgmerge de redimensionner les lignes, histoire d'avoir un diff le plus petit possible. Quant à l'option -N, elle permet de désactiver les recherches inexactes car je veux absolument que la phrase en anglais en version 8.3 corresponde exactement à la phrase en anglais d'une version antérieure pour qu'un remplacement de la traduction puisse intervenir.

Après quelques vérifications, quelques modifications de dernières minutes sur la version 8.3 (et oui, même après validation, il y a encore des retouches à faire), j'ai enregistré les modifs. Évidemment, il reste encore des soucis. Mais un grand nombre de différences de traduction a été résolu grâce à cela. Je vais utiliser les traductions actuelles... si je tombe sur un problème, il sera rapidement corrigé sur toutes les versions.

Voilà mon nouveau projet qui se base sur l'outil OraSnap d'Oracle. Cet outil crée un ensemble de fichiers HTML décrivant l'état d'une base de données Oracle. Donc, voilà, j'ai fait la même chose pour PostgreSQL. Il n'y a évidemment pas une réelle correspondance entre les deux car certaines informations sont disponibles sur Oracle et pas sur PostgreSQL et vice versa. Néanmoins, la majorité des infos systèmes de PostgreSQL est disponible.

Comment cela s'installe ? très simplement. Vous devez avoir installé la version en ligne de commande de PHP (php5-cli sous Ubuntu) ainsi que le pilote PostgreSQL pour PHP (php5-pgsql). Ensuite, il suffit de récupérer le tar.gz de PGSnap et de le déballer dans votre répertoire personnel.

Comment cela s'utilise ? très simplement aussi. Vous exécutez PGSnap sur la ligne de commande. La syntaxe est donnée avec l'option « --help » :

This is pgsnap.php 0.1.0.

Usage:
  pgsnap.php [OPTIONS]... [DBNAME]

General options:
  -d DBNAME       specify database name to connect to
                  (default: "guillaume")
  --help          show this help, then exit
  --version       output version information, then exit

Connection options:
  -h HOSTNAME     database server host or socket directory
                  (default: "localhost")
  -p PORT         database server port (default: "5432")
  -U NAME         database user name (default: "guillaume")

Les connaisseurs remarqueront que ça correspond beaucoup aux options de connexion des outils PostgreSQL en ligne de commande

Bref, « ./pgsnap.php mabase » lancera le script PGSnap sur la base de données mabase et générera un rapport qui sera stocké dans le répertoire mabase_snap_20080402. Si je l'exécute sur la base pagila, cela donne ce résultat. Pas mal, non ?

Il reste encore pas mal de choses à coder, je reste actif sur ce projet (qui se trouve d'ailleurs sur pgFoundry.org) pour aboutir à une version complète rapidement. Il restera à enjoliver les pages web, mais j'avoue que mes talents de designer sont assez primitifs.