gleu's blog

Mardi dernier, un client en support nous appelle à cause d'un problème d'espace disque. Il est en version 8.2. Il dispose de place libre sur d'autres partitions. Rien de plus simple. Il suffit de créer un tablespace sur une des partitions où il reste suffisamment d'espace et d'y déplacer quelques objets pour faire de la place sur le répertoire principal des données. Tout se passe bien : création du répertoire, ajout du tablespace (avec CREATE TABLESPACE), choix de la table à déplacer, et déplacement de la table (avec un ALTER TABLE). Malheureusement, l'opération prends du temps, beaucoup de temps. Et les performances du serveur ont commencé à en pâtir. Le client a voulu interrompre l'opération, quitte à la reprendre plus tard. Pas de soucis, un simple Ctrl-C doit suffire. Et bien non, Ctrl-C et pg_cancel_backend() nous indiquaient bien que la demande d'annulation avait été envoyée mais les opérations sur le disque continuaient et psql ne nous rendait pas la main. Nous avons donc été forcés d'attendre la fin de l'opération.

Pendant ce temps, j'ai commencé à tester sur mon portable et a fouillé dans le code. Et j'ai fini par me rendre compte que rien ne permettait une prise en compte du signal pendant la copie. Autrement dit, vous lancez un changement de tablespace pour la table X de 50 Go, vous essayez de l'annuler au tout début, il vous faudra quand même attendre la fin de la copie des 50 Go pour que votre demande d'annulation soit prise en compte. Très dommageable. Il faut corriger ça. Tout le code se trouve dans la fonction copy_relation_data du fichier src/backend/commands/tablecmds.c. Une boucle s'occupe de la copie :

 for (blkno = 0; blkno < nblocks; blkno++)
 {    
     smgrread(src, forkNum, blkno, buf);
 
     /* XLOG stuff */
     if (use_wal)
         log_newpage(&dst->smgr_rnode, forkNum, blkno, page);
 
     /*   
      * Now write the page.  We say isTemp = true even if it's not a temp
      * rel, because there's no need for smgr to schedule an fsync for this
      * write; we'll do it ourselves below.
      */
     smgrextend(dst, forkNum, blkno, buf, true);
 }

Autrement dit, on lit chaque bloc du fichier source, que l'on copie dans le fichier destination. Une bête copie bloc par bloc, avec aucun moyen de l'interrompre.

De mes lectures dans pgsql-hackers, je me rappelais qu'il existe une fonction appelée CHECK_FOR_INTERRUPTS faisant exactement le travail dont j'avais besoin. J'ai donc uniquement ajouté un appel à cette fonction au début de la boucle, ce qui donne au final :

 for (blkno = 0; blkno < nblocks; blkno++)
 {    
     /* If we got a cancel signal during the copy of the data, quit */
     CHECK_FOR_INTERRUPTS();
    
     smgrread(src, forkNum, blkno, buf);
     
     /* XLOG stuff */
     if (use_wal)
         log_newpage(&dst->smgr_rnode, forkNum, blkno, page);
   
     /*   
      * Now write the page.  We say isTemp = true even if it's not a temp
      * rel, because there's no need for smgr to schedule an fsync for this
      * write; we'll do it ourselves below.
      */
     smgrextend(dst, forkNum, blkno, buf, true);
 }

Une compilation et quelques tests après, je me suis aperçu que tout fonctionnait comme je le souhaitais. L'annulation se fait exactement au moment où je la demande.

J'ai corrigé aussi le déplacement d'une base de données. Le patch terminé, je l'ai envoyé sur pgsql-hackers pour qu'il puisse être testé, relu et enfin commité. Je l'ai même saisi sur le site commitfest. Robert Haas s'en est occupé et l'a finalement commité vendredi sur toutes les versions, de la 8.0 (version à laquelle les tablespaces ont été ajoutées) à la future 9.0.

Enfin, pour moi en tout cas. Il ne reste plus aucun fichier à réserver pour la traduction. Seuls quatre fichiers sont toujours à traduire mais déjà réservés. En attendant leur traduction, il est possible de lire le reste au format HTML ou au format PDF.

Bonne lecture.

Et n'hésitez pas à me faire parvenir tout problème de traduction.

Marc Cousin a beaucoup bossé là-dessus, et il a surtout bien bossé. Le résultat est disponible sur github.com. Le dépôt SVN devient donc inutile et sera archivé rapidement. Pour récupérer le dépôt, c'est très simple. Il vous suffit d'utiliser cette commande :

 git clone git://github.com/gleu/pgdocs_fr.git

et quelques secondes après, vous disposez de toutes les branches, de tous les tags... bref, du dépôt complet des fichiers XML. Cool, non ?

Merci Marc, j'attendais ça depuis un bon moment. Maintenant, tout se fait sur le dépôt git. Si vous voulez les droits d'écriture dessus, il me semble qu'il faut absolument un compte sur github (ouverture gratuite et rapide) et me donner le nom du compte. Allez, je retourne au boulot.

Les nouveautés se succèdent rapidement ces temps-ci et le temps manque encore plus que d'habitude pour parler de tout de façon détaillé.

Vous avez tous dû entendre parler du pgcon qui a eu la semaine dernière à Ottawa. Il y a eu beaucoup de billets de blogs sur le déroulement des festivités. L'un des points les plus intéressants actuellement est ce qui est sorti du Developer Meeting. Le rapport donne beaucoup d'informations sur les prochains développements, que ce soit pour la 9.0 (qui, on l'a appris, devrait bien sortir cet été) et pour la 9.1. Si tout est développé pour cette version, elle promet d'être aussi intéressante que la version 9.1. Je ne peux guère parler des conférences, n'y étant pas. Les quelques échos que j'ai eu étaient très positifs. J'espère pouvoir regarder quelques vidéos sous peu.

Le fait que la 9.0 devrait bientôt sortir est une excellente nouvelle. J'avais un peu peur qu'elle soit repoussée à la rentrée. Le problème que cela pose, c'est pour la traduction de la documentation. En apprenant cela vendredi dernier, j'ai créé la branche 8.4 pour pouvoir commencer le travail. Le merge est pratiquement terminé sur mon portable, après une quinzaine d'heures de travail (oui, c'est long et chiant). Reste encore quatre fichiers, évidemment les plus gros. Je pense nénamoins que ce sera terminé en fin de semaine. Restera la traduction, mais c'est moins effrayant que la période de merge. À noter que Marc travaille sur le passage du dépôt à git, ce serait un très gros plus.

Que dire de plus. J'ai appris ce matin que j'étais élu au comité directeur de PostgreSQL Europe, ce qui est très plaisant. Mon poste sera celui de vice-trésorier, bien que cela ne semble pas très fixé.

Enfin, j'ai un nouveau portable. Le passage de l'ancien au nouveau prend pas mal de temps mais devrait être bien plus agréable (ne serait-ce que la définition de l'écran, 1440x900, c'est autre chose que l'ancien 1280x800). Bref, j'en parlerais plus une autre fois mais je vais retourner au merge.

Ne voulant pas réitérer la bévue pour la version 8.4 de PostgreSQL, je me suis attelé assez rapidement à mettre à jour pgsnap pour PostgreSQL 9.0.

Ce n'est évidemment pas la seule nouveauté de cette version :

• Support complet de la 9.0
  • connexion utilisant le paramètre application_name
  • nouveau rapport sur les ACL par défaut
  • nouveau rapport sur la configuration par paire base/utilisateur;
  • support des tables typées, des contraintes d'exclusion, de la configuration des tablespaces, des informations sur le Hot Standby et le Streaming Replication
• Meilleur support de la 8.4
  • gestion de la colonne relistemp de pg_class
  • gestion des nouvelles colonnes de pg_settings
  • ajout de l'heure de lancement de PostgreSQL et du dernier chargement de la configuration
• Meilleur support des autres versions
  • nouveau rapport sur les séquences
  • nouveau rapport sur les Large Objects
  • détection des modules contrib
  • ajout des commentaires sur les objets.

Pour télécharger, c'est ici. Vous pouvez consulter aussi cet exemple de rapport.

J'aurais pu attendre un peu avant de sortir cette version. Cependant, je vais être maintenant bien occupé par la mise à jour de la traduction française du manuel de PostgreSQL (enfin, dès que la beta 2 sort, donc à priori rapidement). Je n'aurais plus trop de temps pour m'occuper de pgsnap en dehors de quelques corrections de bugs. Donc voilà pourquoi cette version sort dès maintenant.

Et puis, j'ai en tête un changement important pour pgsnap. Peut-être pour la prochaine version.

C'est ce moment de l'année où les tests sont de rigueur...

guillaume@laptop:~$ psql -V
psql (PostgreSQL) 9.0beta1
contient une gestion avancée de la ligne de commande

Il nous a fallu quand même ce soir trois heures de discussion, codage et test avec Dave pour finaliser la 1.12. Grand merci aux outils de type pidgin, Google Chat et autres du même type, c'est quand même bien plus efficace que le mail dans ce cadre.

Une annonce officielle sera faite lundi.

Ça fait un petit moment que je n'ai pas parlé de pgsnap. Il y a eu assez peu de changements ces derniers temps. Et assez peu de motivation pour améliorer cet outil. Mais cela pourrait bien changer rapidement.

Tout d'abord, une petite information. J'ai déplacé le code source de pgsnap sur github. Donc, contrairement à ce qu'indique la page sur pgfoundry, les sources sont maintenant sur la page github de pgsnap. En soi, ça ne change pas grand-chose à part pour les développeurs. Je vais continuer à utiliser pgfoundry pour la partie web et news. Cela étant dit, je n'exclue pas la possibilité d'externaliser ça aussi.

La vraie news concerne l'orientation du projet. Pour l'instant, pgsnap crée un rapport composé de plusieurs pages HTML. C'est très bien actuellement mais cela pose quelques soucis. Le premier concerne le fait qu'un utilisateur peut se trouver avec plein de différents rapports d'une même base, placés un peu partout sur son disque local. Il est assez difficile de faire la relation entre chacun (notamment si cette personne renomme la base...), de les partager avec ses collègues, etc. Le deuxième soucis, qui me dérange de plus en plus, est la difficulté de voir les différences entre deux rapports pour savoir comment à évoluer la base dans le temps. C'est un des éléments de la TODO list qui me pose le plus de questions.

Or, il se trouve que j'ai peut-être une solution pour ces deux problèmes. J'étais partie au départ avec l'idée de fournir un rapport composé de pages HTML pour reproduire le comportement de orasnap. Mais ce n'était certainement pas le plus futé à faire. Le mieux serait certainement de récupérer toutes les données dans un format du style sauvegarde SQL de PostgreSQL ou plus simple dans un format CSV. L'idée est de pouvoir placer toutes les données dans une seule et même base PostgreSQL de reporting et de construire un outil capable d'afficher les informations sur les différents rapports stockés dans la même base, voire de regarder les différences entre deux rapports.

Voilà. L'idée me plaît. La partie « outil de visualisation » me semble assez complexe. Mais les avantages sont suffisamment importants pour songer à modifier complètement le comportement de pgsnap. Quitte à fournir une deuxième application, capable de lire ce « dump » et de créer les rapports HTML identiques à la première conception de pgsnap.

Comme les sources de pgsnap sont sur git, je vais certainement créer une nouvelle branche pour travailler sur ce concept sans déranger le reste du développement. Car, oui, il va falloir continuer le développement normal de pgsnap. Ce dernier est compatible basiquement avec la 9.0 mais il faudrait qu'il retrouve bien plus d'informations sur cette dernière. Donc la branche master sera utilisé pour ajouter une gestion plus complète de la version 9.0 et une autre branche sera créée pour tester et mettre en place le nouveau concept.

Suite du « Installer et débuter avec PostgreSQL », ce livre donne un grand nombre d'informations sur les requêtes SQL, les objets SQL, bref sur la façon d'utiliser PostgreSQL. Je trouve ce livre beaucoup plus intéressant, en tout cas pour moi. J'y ai re-découvert pas mal de choses. Donc, cette fois-ci, ça peut aussi être intéressant pour les pros.

Là encore, format PDF, 11 €. Excellent rapport qualité/prix.

Bref, vivement le prochain

(petite info qui peut avoir son importance pour certains, j'ai fait la relecture technique de ce livre, comme du précédent)

La semaine dernière, j'avais fourni quelques statistiques sur le site de documentation français sur PostgreSQL. Je me suis dit qu'il serait intéressant d'avoir aussi quelques statistiques sur l'activité du forum. Alors voici quelques chiffres et quelques graphes sympathiques.

Commençons par la quantité de messages par thèmes :

Attention, qu'on soit bien d'accord, je n'ai pas regardé le contenu de chaque message pour savoir s'il correspondait vraiment à ce thème. J'utilise simplement le nom du forum. Néanmoins, participant beaucoup au forum, j'estime qu'ils sont en très grande majorité dans le bon forum.

Que peut-on en dire ? pas grand-chose en dehors que les thèmes les plus fréquents sont assez logiques : installation, optimisation, réplication... et un très gros général. Donc rien de bien surprenant là.

Voyons voir maintenant la progression du nombre de threads par mois (un thread étant une question lançant un débat) :

Après une petit chute en août, le nombre de threads est en augmentation constante, ce qui est tout à fait satisfaisant. Par contre, le nombre de threads est relativement bas (en gros, un peu plus de deux questions par jour ouvré).

Plus intéressant, le nombre de questions et de réponses :

Dis autrement, le posteur ne se satisfait généralement pas de la première réponse. En moyenne, ça nous donne quelque chose comme 5 réponses par question. Plutôt élevé à mon goût, mais ce n'est pas que négatif. Ça peut aussi indiquer que le posteur est intéressé et souhaite d'autres informations.

Bien pire est le nombre de lectures du forum par mois :

Je n'ai aucune explication à cette baisse de fréquentation des lecteurs du forum. Ça tombe à très très peu car j'ai oublié de virer la statistique d'avril (qui n'a aucun sens, vu qu'on est le 5 avril).

Si on regarde du côté des participants au forum, j'avais assez peu d'illusions là-dessus :

Autrement dit, Marc et moi comptabilisons pratiquement autant de messages que le reste du monde. Ce n'est pas une surprise car je ne vois que nous deux répondre aux messages.

Passons à des nouvelles plus gaies, le temps de réponse à un message dans le forum. J'indique assez souvent en formation qu'il ne faut pas hésiter à poser des questions sur le forum ou sur les listes de discussion (anglaises et française) car le temps de réponse est très court et que la réponse est très souvent techniquement exacte. Ne pouvant pas facilement juger (avec une requête SQL) du second, il est par contre aisé d'avoir la réponse au premier, ie le délai avant la première réponse. J'ai commencé petit joueur avec un délai à la journée :

Il y a de très fortes chances que vous ayez une réponse dans l'heure, voire dans la demi-journée si vous êtes malchanceux (ie, Marc et moi absents). Je me suis donc enhardi et j'ai regardé par tranche de dix minutes sur la première heure :

En gros, il y a de fortes chances qu'une réponse arrive en moins d'une demi-heure.

Quand aux jours des posts, ce sont tous les jours ouvrés avec environ 800 posts par jour ouvrés, mais seulement 400 pour le week-end complet.

Je crois que la légende est inutile, c'est super simple à comprendre

Enfin, dernière statistique, le nombre de messages par heure dans la journée, là non plus, pas de révolution, les messages sont envoyées dans la journée de travail :

Par contre, les gens mangent plus tôt que ce que je pensais le midi

Voilà en gros ce qu'on peut dire de l'activité du forum web français sur PostgreSQL. Et autant le répéter ici, n'hésitez pas à venir poser vos questions, vous y serez bien reçu.