gleu's blog

Aller au contenu | Aller au menu | Aller à la recherche

lundi, juillet 26 2010, 23:14

Reset statistics for one table or one function

Par Guillaume Lelarge - PlanetPostgreSQL - Lien permanent

During 9.0 development, Magnus Hagander added two system functions to reset an object's statistics. The first one, pg_stat_reset_single_table_counters(), to reset a statistics of a specific relation, the second one, pg_stat_reset_single_function_counters(), to reset a function's statistics. I don't know why but it fell off my radar for some reason during the development of pgAdmin 1.11.

So, now that we can start adding new features to pgAdmin, I worked on a patch to use these two system functions.

Say you have a table named t1. It has some statistics. You can see them on the Statistics tab of the browser window:

ticket186_1.png

You want to reset its statistics. Right-click on the table's name in the brower, select "Reset statistics":

ticket186_2.png

pgAdmin will ask you to confirm the action:

ticket186_3.png

And, if you answered yes, pgAdmin will fire the "SELECT pg_stat_reset_single_table_counters(<oid of the table>)" query, and display the new counters:

ticket186_4.png

You probably noticed it didn't reset all counters. That's right. Index counters need to be reset separately. That's something missing on my patch. Something I should fix ASAP.

aucun commentaire aucun rétrolien

dimanche, juillet 25 2010, 22:10

Some news on pgAdmin

Par Guillaume Lelarge - PlanetPostgreSQL - Lien permanent

I wanted to write something about pgAdmin, but didn't find time to do it. But I guess now is a good time.

pgAdmin 1.12 is still in beta. I fixed a bug yesterday, but I have to say that we have less and less bug reports. Don't forget we need your help to find and fix bugs. And we also need your help to translate the UI. If you've got some spare time, your help woud be greatly appreciated.

Meanwhile, Dave and Magnus moved our repository to GIT. We were using SVN, and Dave even wrote some notes on how to use git-svn. I used it a lot during the coding of 1.12. But, even with git-svn, the move to GIT is really welcomed. So, we now have a few repositories, the two main ones being pgadmin3 and pgadmin-www.

And yesterday, Dave added a tag for the new 1.13 development branch. This is also news to us. Last year, we waited quite some time after the release of 1.10 before opening the repo to new features. This year, the PostgreSQL hackers branched early to ease the development of 9.1. And the pgAdmin guys did the same to ease the development of 1.14.

We already have some new features commited. But I will describe them in another post.

2 commentaires aucun rétrolien

jeudi, juillet 15 2010, 23:09

GIT, cette nouvelle mode

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Donc PostgreSQL passe à git mi-août. Du coup, un peu tout le monde y passe. pgAdmin commence son passage ce soir (avec le dépôt pgagent par exemple). Slony se pose officiellement la question. Quant aux dépôts de PostgreSQLfr, ils y sont passés depuis un mois en gros.

Je trouve ça plutôt bien. Ça uniformise les dépôts sur un système véritablement excellent. Pour une fois qu'on uniformise vers le haut, on ne va pas se plaindre :)

aucun commentaire aucun rétrolien

jeudi, juillet 15 2010, 13:27

Manuel 9.0 beta 3 disponible

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Et non, pas de vacances pour moi pour l'instant. Les deux semaines d'inactivité sur ce blog ont une raison : la mise à jour de la traduction du manuel en beta3, mais aussi et surtout du travail sur pgAdmin (dont je parlerais plus tard, certainement en fin de semaine).

Bref. Tout ça pour dire que la traduction française du manuel de PostgreSQL 9.0 beta 3 est disponible. Normalement, tout est traduit. Peut-être mal, il va falloir que je fasse une passe importante de relecture. En attendant, un lien pour consulter la doc en ligne et un lien pour récupérer le PDF.

Merci de me rapporter tout soucis constaté dans la traduction.

Update: correction du lien vers le PDF. Merci à "Fly".

2 commentaires aucun rétrolien

samedi, juillet 3 2010, 11:45

Comment un problème constaté chez un client peut se transformer en un nouveau patch pour PostgreSQL

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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.

un commentaire aucun rétrolien

samedi, juin 26 2010, 23:44

Vous voulez connaître les nouveautés de la 9.0 ?

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Alors allez lire le document rédigé par Marc Cousin. Il existe en version française et en version anglaise. Josh Berkus semble l'avoir beaucoup apprécié.. Et avec raison, car ce document est une mine.

aucun commentaire

jeudi, juin 17 2010, 21:49

French translation of 9.0-beta 2 manual is available

Par Guillaume Lelarge - PlanetPostgreSQL - Lien permanent

It's been a hard work, and it's nearly done. There are still four files to update, and all are under work by the french team. You can read it here, or grab it here in PDF.

So, now, I can get back to work on pgAdmin. And that's cool :)

2 commentaires

jeudi, juin 17 2010, 20:06

Fin de la traduction du manuel de la 9.0 (beta 2)

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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.

aucun commentaire

lundi, juin 7 2010, 00:09

Traduction du manuel de la 9.0 beta 2

Par Guillaume Lelarge - PostgreSQL - Lien permanent

La beta 2 de la 9.0 sort aujourd'hui (oui, on est déjà lundi, même si c'est de peu), tout comme la version 1.12 beta 2 de pgAdmin.

J'en profite pour dire que j'ai fait le merge de la traduction vers la beta 2 et que j'ai commencé sérieusement la traduction. On est passé de 247 fichiers à traduire à 32. C'est évidemment les plus gros qui restent... :-/

Bref, pour les impatients, le manuel français de la 9.0 est disponible. Mais attention, il y a toujours des (plus ou moins gros) morceaux en anglais.

2 commentaires

mercredi, juin 2 2010, 19:04

Et hop, un dépôt git pour la traduction des manuels de PostgreSQL et de Slony

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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.

un commentaire

dimanche, mai 30 2010, 19:59

La traduction de la 9.0 peut commencer

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Le merge est terminé depuis un bon moment. J'attendais de pouvoir proposer une interface simpliste pour la réservation des fichiers et surtout la récupération du diff entre ancienne version et nouvelle version de chaque fichier.

Cet après-midi, j'ai donc écrit cette interface, ainsi qu'un outil pour intégrer toutes ces informations dans une base de données. Le résultat est disponible à cette URL : http://www.postgresql.fr/~guillaume/traduction/liste.php

Alors, oui, c'est en grosse partie moche, sauf la partie visualisation du patch. Ça n'a pas beaucoup de fonctionnalités. Remarquez que c'est clairement pas le but. Je me fous de la présentation en dehors du patch. Mon but est de fournir une interface simple permettant de travailler pour se mettre au travail le plus vite possible. C'est chose faite. Je suis content :)

Pour réserver un fichier, il suffit de cliquer sur le nom du fichier, puis d'indiquer son nom dans le champ texte « Traducteur ». Le patch se trouve en dessous. Si vous ne disposez pas d'un accès au SVN, je peux vous fournir le fichier. Il suffit de m'envoyer un mail à guillaume at lelarge point info. Une fois le fichier traduit, il suffit là-aussi de me l'envoyer. Je l'intègrerais dans le SVN en vous mettant comme traducteur.

Merci.

aucun commentaire

mardi, mai 25 2010, 19:07

Peu de temps, donc quelques news rapides

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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.

aucun commentaire

mercredi, mai 19 2010, 01:19

New minor releases == new french manuals

Par Guillaume Lelarge - PlanetPostgreSQL - Lien permanent

It's been quite a long time since I last blogged on Planet PostgreSQL. I think it is time to blog a bit more, and also more frequently.

Last week-end, I updated the french translation of the PostgreSQL manuals. People speaking (or at least reading) french can have a look on the french docs website. We have manuals for all stable releases (7.4, 8.0, 8.1, 8.2, 8.3, and 8.4 releases). We still don't have 9.0. I usually start to work on the upcoming release when beta 1 is available, but couldn't do it for this release : too much pgAdmin related work. I'll start as soon as beta 2 is available.

Last week-end, I also updated the french translation of Slony manuals (but the website is not completely translated). We have 1.2 and 2.0 available.

aucun commentaire

lundi, mai 17 2010, 23:35

Traduction d'un peu de tout

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Le week-end dernier, j'ai travaillé sur les traductions des prochaines mises à jour. Du coup, le site français de la documentation sur PostgreSQL dispose déjà des manuels des version 8.4.4, 8.3.11, etc. J'en ai profité aussi pour mettre à jour les manuels de Slony, branche 1.2 et 2.0. Par contre, je ne sais pas quand Damien aura le temps de les mettre sur le site, surtout que ce dernier commence à dater un peu.

Dernière nouveauté de traduction, l'installeur d'EnterpriseDB est disponible en français. J'avais fait la traduction il y a un bon moment, mais les petits gars de Dave Page ont mis beaucoup de temps pour l'intégrer... jusqu'à ce que je m'aperçoive en version 9.0 beta 1 que je m'étais trompé dans l'encodage. C'est enfin corrigé et l'installeur de la 8.4.4 dispose donc de la traduction. Allez, hop, deux copies d'écran pour la peine :

Lancement de l'installeur

2010-05-17--22-55-30.jpg

Installation en cours

2010-05-17--23-24-05.jpg

Sympa, non ? moi, j'aime bien.

Que dire de plus... la beta 2 n'est toujours pas sortie, et ne risque pas de sortir avant au moins une semaine pour cause de PGCon, ce qui m'agace bien (qu'elle ne soit pas déjà sortie et que je ne sois pas au PGCon... sigh...). Ça sent un bon retard pour la traduction du manuel de la version 9.

Le bon côté, c'est que ça me permet de travailler sur des outils comme pgpool, pgbouncer, slony. Pour les deux premiers, j'ai proposé un patch pour ajouter les options longues. Patch accepté pour pgpool, patch que j'ai donc commité dimanche après-midi. Pas de nouvelles des développeurs de pgbouncer, peut-être en voyage pour PGCon (chanceux...). Au départ, je voulais ajouter la gestion du paramètre application_name, disponible à partir de la 9.0. Je me suis un peu cassé les dents avec les poolers de connexion. Par contre, pour Slony, ça semble bien plus simple. Je pense que je vais proposer un patch assez rapidement pour ce dernier. Il serait aussi intéressant que les pilotes le prennent en compte (je pense notamment au pilote Perl et au pilote PHP). Bref, du boulot sur la planche, ce qui est cool :)

aucun commentaire

jeudi, mai 13 2010, 19:18

pgsnap, version 0.6

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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.

aucun commentaire

jeudi, mai 6 2010, 00:28

Maintenant que l'annonce est faite...

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Enfin, pour PostgreSQL car pour pgAdmin, on attend toujours. J'ai finalement réussi à corriger un bug dans pgAdmin qui me donnait du mal. Et j'ai terminé le Visual Tour pour la version 1.12. Il ne manque vraiment plus que l'annonce de la beta 1 de pgAdmin :)

Bref, on est en période beta. Ça veut dire correction de bugs. Ça veut dire aussi que, pour les codeurs d'outils tiers, du boulot est en prévision pour s'assurer de la compatibilité de leur outil avec la prochaine version. On va espérer que les développeurs de Slony vont penser à ça (quoiqu'il semble me rappeler avoir vu passer un patch pour ça il y a peu, donc on peut être optimiste). Ceci dit, le mieux pour tout le monde, c'est de le tester soi-même. En ce qui me concerne, ça veut dire que j'ai du boulot pour pgsnap. Un patch récemment a permis d'utiliser pgsnap avec une 9.0, mais pas d'en tirer le meilleur profit.

Mais surtout, une beta 1 de PostgreSQL, pour moi, ça veut dire une traduction du manuel à mettre à jour. Pour les outils en ligne de commande livrés avec PostgreSQL, c'est déjà fait. Mais pas encore pour la documentation. Donc voilà, à partir de demain, c'est mon occupation principale.

aucun commentaire

samedi, mai 1 2010, 01:01

Beta 1 coming up

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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

beta 1 de pgAdmin 1.12

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.

3 commentaires

jeudi, avril 29 2010, 16:30

GSoC pgAdmin

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Je viens d'avoir la nouvelle par Luis. Sa proposition de projet GSoC pour pgAdmin a été acceptée. Et je suis son mentor, ce qui me fait bien plaisir.

Du coup, je viens de jeter un œil aux statuts des différentes propositions. Six ont été acceptées. Deux concernent pgAdmin, un concerne phpPgAdmin et les trois autres concernent PostgreSQL directement.

Le projet que je mentor-ise doit permettre la création d'un outil de modélisation graphique d'une base à partir de pgAdmin. Luis Ochoa est l'étudiant qui a proposé cette idée. Nous avons une grande confiance en lui. Il a déjà codé le constructeur graphique de requêtes (GQB, Graphical Query Builder) de l'éditeur de requêtes. Il connaît donc bien pgAdmin et la partie graphique. Il y a de fortes chances que le résultat de son travail sera inclus dans la 1.14.

À noter que le mentor du projet pour phpPgAdmin est Jehan-Guillaume de Rorthais. Bien content pour lui aussi.

aucun commentaire

lundi, avril 26 2010, 11:11

Évolutions de pgsnap

Par Guillaume Lelarge - PostgreSQL - Lien permanent

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

aucun commentaire

samedi, avril 24 2010, 23:33

Petit résumé des quatre dernières semaines sur pgAdmin - 5

Par Guillaume Lelarge - PostgreSQL - Lien permanent

Pas mal de nouveautés cette fois sur pgAdmin, à la fois en matière de corrections de bugs mais aussi en nouvelles fonctionnalités.

Commençons par les corrections de bug. Erwin a trouvé le temps de nous concocter quelques rapports de bugs. Apprendre l'existence d'un bug n'est pas plaisant, le corriger l'est beaucoup plus. Il a remarqué par exemple que les règles d'une vue étaient oubliés dans les requêtes permettant de recréer la vue. Ce bug a été corrigé assez rapidement. Autre exemple, les groupes n'étaient pas proposés dans la liste déroulante permettant d'indiquer le propriétaire d'un objet. Là-aussi, le correctif a été plutôt simple.

Dave a découvert un bug assez étrange sur la fenêtre d'état du serveur. Le composant liste utilisé utilise par défaut le composant natif sous Mac OS X. Or, ce composant natif permet de réaliser des tris dans la liste. C'est une fonctionnalité très intéressante pour cette plateforme. Malheureusement, notre méthode pour la mettre à jour causait le vidage de certaines lignes, pour aboutir à un affichage illisible. J'ai travaillé sur ce correctif et j'ai fini par aboutir à une solution en deux étapes. Pour la branche 1.10, on empêche l'utilisation du composant natif, ce qui a pour effet de supprimer le tri possible sous Mac OS X. Pour la branche en cours de développement, j'ai ajouté la possibilité de trier les colonnes de chaque rapport, quelque soit la plateforme, en désactivant toujours le comportement natif sous Mac OS X. Voici une copie d'écran de la fenêtre d'état :

status.png

L'affichage est toujours trié par défaut par PID. En cliquant sur l'entête d'une colonne, le tri est modifié pour se faire par rapport à cette colonne. Ça faisait longtemps que je voulais ajouter cette fonctionnalité. Je n'imaginais pas du tout avoir ça pour la future 1.12, et je n'y pensais vraiment pas en commençant à travailler sur ce bug.

Josh Berkus s'est plaint, avec raison, qu'il était impossible de sélectionner un autre utilisateur pour créer une nouvelle connexion dans l'outil de requêtage. Vu qu'il s'agit d'une nouvelle fonctionnalité, elle fera partie de la 1.12 :

queryconnection.png

Josh a aussi remarqué que la gestion des fichiers récents était pour le moins étonnante. J'ai corrigé ça en permettant à un outil de requêtage d'alerter les autres outils de requêtage pour qu'ils puissent recharger la liste des derniers fichiers ouverts.

L'option de stockage d'une colonne est enfin modifiable dans la fenêtre des propriétés d'une colonne :

column.png

Dans les petits trucs en plus, on peut noter un élément supplémentaire dans le menu contextuel d'un serveur : « Reload configuration ». Cette action se contente d'exécuter un « SELECT pg_reload_conf(); » sur le serveur.

reloadconf.png

Magnus a écrit un petit patch permettant de demander le nom du fichier à utiliser pour l'export de données avant l'exécution de la requête (histoire que l'utilisateur n'ait pas à attendre le temps de l'exécution de la requête pour fournir le nom du fichier à sauvegarder). Il s'est aussi étonné que la fenêtre de maintenance utilisait la connexion du navigateur pour faire le VACUUM ou l'ANALYZE. Vu que ce sont des opérations potentiellement (très) longues, j'ai changé cela pour que la fenêtre utilise sa propre connexion, laissant à l'utilisateur la possibilité d'utiliser le navigateur pendant l'exécution de l'opération de maintenance.

J'ai travaillé aussi avec Ashesh Vashi pour corriger un bug dans l'outil de création graphique de requêtes.

La grosse nouveauté a été enregistrée e matin même dans les sources. Depuis plus d'un an, j'avais dans l'idée d'ajouter la possibilité de créer des groupes de serveurs. J'avais laissé un peu de côté. Jehan-Guillaume de Rorthais l'a fait tout récemment pour phpPgAdmin, ce qui m'a poussé à jeter un œil sur cette fonctionnalité. J'en ai un peu bavé mais c'est fait. La preuve :

browser.png

Et voilà. Pas mal, non ? :)

Pour la suite, nous sommes en train de travailler sur les dernières fonctionnalités. La beta 1 de PostgreSQL 9.0 doit sortir d'ici une semaine, cela nous laisse peu de temps. En fait, il reste peu à faire et Ashesh a déjà investi pas mal de temps sur ce qu'il nous manquait. Pas encore commité, mais ça ne devrait plus tarder. En ce qui me concerne, il me reste toujours la contrainte d'exclusion. J'avoue que j'ai du mal à travailler dessus. Mais bon, on va y arriver.

aucun commentaire

- page 1 de 63