PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

PGWN - 15 janvier 2007

PostgreSQL Weekly News | PGWN - 15 janvier 2007

Par SAS le 19/01/2007 - 13:19


Les mises à jours 8.2.1, 8.1.6, 8.0.10, 7.4.15 et 7.3.17 sont désormais disponibles.
Les paquetages existent pour Debian, Fedora, Fink, FreeBSD, Red Hat et Ubuntu. Ne tardez pas à faire les mises à jour.

Les nouveautés des produits dérivés

PostgreSQL Local

Le German PostgreSQL Usergroup (Groupe Allemand d'Utilisateurs http://www.pgug.de) crée trois nouveaux prospectus en anglais et en allemand. Les sujets en sont :

  • un résumé de PG ;
  • PG et la réplication ;
  • PG et les SGBD concurrents.

Pour participer, contacter info at pgug dot de.

N'oubliez pas de soumettre vos propositions pour PGCon 2007. Cet évènement se déroulera à Ottawa, Ontario, Canada. Dernière limite pour les propositions, le 19 janvier.
http://www.pgcon.org/2007/submissions.php

Il y aura un stand PostgreSQL lors du FOSDEM les 24 et 25 février à Bruxelles, Belgique. La plupart des célébrités de la communauté PostgreSQL de l'UE y sera. Contacter de@postgresql.org pour participer. http://www.fosdem.org/2007/

Pavel Stehule assure un cours sur les procédures stockées sous PostgreSQL, le 11 janvier 2007 à Pragues. Cours en tchèque. Trop tard pour y participer.
http://www.root.cz/zpravicky/skoleni-o-ulozenych-procedurach-v-postgresql/

La communauté italienne de PostgreSQL organise une journée PostgreSQL cet été. Marquez ce lien pour participer.
http://www.pgday.it

Gavin Sherry tient une miniconf PostgreSQL lors de Linux.Conf.Au à Sydney mardi 16 janvier 2007.
http://lca2007.linux.org.au/Miniconfs/PostgreSQL
Il est trop tard pour y être ;-)

PostgreSQL dans les média


PostgreSQL Weekly News vous est présenté cette semaine par David Fetter, Devrim GUNDUZ et Robert Treat.
Adaptation francophone de Stéphane Schildknecht.

Pour voir vos propositions incluses dans le prochain numéro, envoyez les avant lundi 0h00 à david at fetter dot org

Correctifs appliqués

Alvaro Herrera a commité :

  • le correctif de Marko Kreen qui remplace les define DISABLE_ZLIB inutiles de pgcrypto par HAVE_LIBZ du core ;
  • le correctif d'autovacuum qui évite de laisser des Xids non permanents dans les bases qui n'acceptent pas de connexion. Appliqué uniquement à la branche 8.1 car 8.2 (et HEAD) n'ont pas ce problème ;

Michael Meskes a commité :

  • l'ajustement du fichier nécessaire à MinGW en fonction du fichier attendu par le nouveau script d'installation avec le bon numéro de port ;
  • la simplification de la gestion de regression d'ecpg et l'ajout du correctif de Joachim Wieland du bug dans la suite de regression sous OpenBSD ;
  • dans ecpg, l'application du correctif de Joachim pour l'option --regression. Puisque cette option marque les fichiers .c, les variables d'environnement ne sont plus nécessaires. Un fichier MinGW spécial a été créé avec le message d'erreur particulier. Le numéro de port n'est plus écrit dans le journal lors du déroulement des tests de régression.

Neil Conway a commité :

  • l'ajout d'une note dans les docs pour décrire le comportement du tri et de l'égalité de NaN (Not a Number). D'après un fil de discussion récent sur -hackers, c'était nécessaire car Postgres se comporte différement de la plupart des implantations de NaN, dont IEEE754 ;
  • un correctif de Magnus Hagander et Joachim Wieland à pgsql/src/tools/msvc/gendef.pl qui corrige deux problèmes : gendef fonctionne à l'intérieur de visual studio - avec l'utilisation d'un fichier temporaire plutôt qu'une redirection (pour diverses raisons, il n'est pas possible de rediriger dumpbin) et gendef ne peut travailler que sur des *.obj, dans le cas contraire, il produira des résultats hasardeux dans divers scénarios de construction lorsqu'il tentera de jouer un logfile ;
  • le correctif de pgsql/src/tools/msvc/build.bat qui active une sortie verbeuse lors de la construction de tous les projets. Le même niveau de sortie était utilisé lors de la construction d'un seul projet auparavant. Il était réellement nécessaire de produire des informations raisonnables sur ce qu'il se passe (le mode non-verbeux dit juste "starting build of foo" et "done building foo", à peu de choses près).

ISHII Tatsuo a commité :

  • le correctif rétro des versions 8.0, 7.4 et 7.3. Celui-ci appelle srandom() en lieu et place de srand(). pgbench appelle random() par la suite, alors qu'il devrait appeler srandom(). Sur la plupart des plateformes, à l'exception de Windows srandom() est en fait équivalent à srand(). Le bogue ne touche donc que les utilisateurs de Windows users. D'après le rapport de bogue de Akio Ishida ;
  • la mise à jour de l'année de copyright dans contrib/pgbench.

Bruce Momjian a commité :

  • la suppression des items traités et devenus inutiles de la TODO LIST, dont "Fix memory leak from exceptions" (fait), "Allow constraint_exclusion to work for UNIONs like it does for inheritance, allow it to work for UPDATE and DELETE statements, and allow it to be used for all statements with little performance impact" (fait), "Add estimated_count(*) to return an estimate of COUNT(*)" (plus souhaité)
  • la mise à jour de la description de to_char("CC") ;
  • la mise à jour du message d'erreur dans pgsql/src/backend/parser/analyze.c ;
  • la mise à jour des messages ORDER BY UNION (encore) ;
  • la mise à jour des messages des expressions/fonctions UNION/INTERSECT/EXCEPT ORDER BY ;
  • l'amélioration des messages d'ORDER BY dans UNION qui utilisent les nouvelles expressions d'ORDER BY ;
  • l'ajout à la TODO LIST de : "Add URL item for psql -c changes"
    http://archives.postgresql.org/pgsql-hackers/2007-01/msg00291.php;nbsp;;
  • l'ajout à la TODO LIST de : "Fix transaction restriction checks for CREATE DATABASE and other commands"
    http://archives.postgresql.org/pgsql-hackers/2007-01/msg00133.php ;
  • l'ajout à la TODO LIST de : "Add URL for PQexec() for disallowing multiple queries"
    http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php ;
  • l'ajout à la TODO LIST de : "Extend timezone code to allow 64-bit values so we can represent years beyond 2038."
    http://archives.postgresql.org/pgsql-hackers/2006-09/msg01363.php
  • l'ajout à la TODO LIST de: "Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h and consider making it more configurable in future releases."
  • le correctif de L Bayuk qui permet à BCC de compiler libpq et psql ;
  • l'ajout pour pg_ctl -w de la référence aux variables d'environnement additionnelles et à pgpass ;
  • la suppression dans le makefile SGML du tag .SECONDARY afin que les règles html fonctionnent correctement ; amélioration de la documentation et des commentaires ;
  • l'amélioration des règles de construction SGML pour les sorties non-HTML output, per Peter Eisentraut ;
  • la mise à jour du script de copyright pour permettre les espaces entre les tirets longs (dash) ;
  • dans le Makefile SGML, le positionnement des cibles appropriées aux appels récursifs ;
  • l'ajout de "Improve merge join performance by allowing mark/restore of tuple sources" à la TODO list ;
  • le correctif de Michael Fuhr qui actualise les références RFC pour UTF-8. La RFC 2044 est rendue obsolète par la RFC 2279, elle même rendue obsolète par la RFC 3629 ;
  • la documentation SGML doit être construite plusieurs fois pour obtenir les bons index ; d'où l'ajout de l'option 'draft' pour désactiver ce fonctionnement ;
  • le passage des log_temp_files en kilooctets et la suppression des appels à trace ;
  • la suppression des appel à la macro trace à partir des nouveaux log_temp_files, en attendant une recherche plus approfondie ;
  • le correctif de Heikki Linnakangas qui autorise d'autres octets de statut à cinq tupes en utilisant les octets de poids fort du champ nattr et en renommant le champ ;
  • dans la TODO list le passage en "fait" de : "Add ability to monitor the use of temporary sort files" 
  • le correctif de Bruce Moran qui ajoute une variable de configuration log_temp_files pour journaliser l'utilisation de fichiers temporaires ;
  • dans le TODO list, le passage en "fait" de : "Allow the creation of indexes with mixed ascending/descending." Le correctif ORDER BY ... NULL FIRST/LAST de Tom Lane l'implante.

Tom Lane a commité :

  • un correctif de gestion du format CC (century) dans to_date/to_char. D'après le standard, le 21è siècle s'étend de 2001 à 2100, et non de 2000 à 2099. Autant que cela fonctionne ainsi. Per bug #2885 de Akio Iwaasa. Correctif rétro de 8.2, mais pas plus puisqu'il s'agit en fait d'une modification de définition ; les utilisateurs des autres branches recherchent certainement plutôt la stabilité ;
  • l'ajout de notes à pgsql/src/backend/access/nbtree/README concernant les règles mathématiques de base que le système tient pour vrai pour les opérateurs d'une famille btree. Il s'agit essentiellement de clarifier ma propre pensée de ce que le planificateur peut assumer dans un but d'optimisation. (dépoussié un vieux livre d'algèbre abstrait...) ;
  • la correction d'un problème de performance dans les bases contenant un grand nombre de tables (ou d'autres types d'entrées dans pg_class) : le temps d'exécution de la fonction pgstat_vacuum_tabstat, invoquée au démarrage de VACUUM, est proportionnel au nombre de stats d'entrée dans la table multiplié par le nombre de lignes dans pg_class ; en d'autres mots O(N^2) si les informations du collecteur de stats sont complètes. Le parcours de liste à été remplacé par une table de hachage pour le ramener à un comportement O(N). D'après un rapport de kim at myemma.com. Correctif rétro jusqu'à 8.1; 8.0 and before use different coding here ;
  • la gestion par nodeMergejoin des ordres de tri DESC et/ou NULLS FIRST. N'a été testé à ce jour qu'en "hackant" le planificateur...
  • l'assurance que BYTE_ORDER est défini sur les constructions 64-bits Solaris, per Stefan Kaltenbrunner ;
  • la modification de l'API planner-to-executor pour que le planificateur annonce à l'exécuteur lles opérateurs de comparaison à utiliser pour les noeuds des plans qui comprennent des comparaisons de tuple (Agg, Group, Unique, SetOp). Auparavant, l'exécuteur recherchait l'opérateur d'égalité par défaut pour le type de données, ce qui n'était pas satisfaisant, puisqu'il est possible que les données passées au nÅ“ud soit ordonnées par une classe d'opérateurs autre que celle par défaut et qui peut avoir une idée incompatible de l'égalité. Le planificateur sait comment les données ont été triées et peut donc fournir l'opérateur d'égalité adéquat. Qui plus est, cette modification déplace un certain nombre de parcours du catalogue de l'exécuteur au planificateur, ce qui peut accélérer le démarrage des requêtes déjà planifiées. Le planificateur a été modifié pour supprimer d'autres hypothèses cavalières quant à l'utilisation de l'opérateur par défaut. L'information "nulls first/last" a également été ajoutée au nÅ“ud du Plan pour une jointure de fusion --- ni le planificateur, ni l'exécuteur ne savent le gérer, mais au moins l'API est en place ;
  • quelques modifications dans la documentation d'ORDER BY ; en particulier la mise en relief de la différence entre ORDER BY x, y DESC et ORDER BY x DESC, y DESC ;
  • l'ajout d'une citation d'un article de 1991 de Seltzer et Yigit concernant la gestion des tables de hachage dans pgsql/src/backend/access/hash/README. L'article décrit clairement la plupart des idées présentes dans notre code de hachage, mais pour autant que j'ai pu constater, il n'y a pas d'héritage direct de code. (Mike Olsen rappelle la discussion de cet article dans les meetings Postgres, mais estime que "cela n'a probablement servi à Postgres que dans la phase de conception". Margo elle-même avour qu'elle n'était pas impliquée dans le code Postgres du hachage.) Créditons ce qui doit l'être, même 15 ans après ;
  • le correctif de Magnus Hagander à pgsql/src/tools/msvc qui corrige vcbuild pour permettre la construction sans OpenSSL mais/ni zlib ;
  • l'ajout d'un README dans pgsql/src/tools/msvc avec la documentation de Magnus Hagander et Dave Page ;
  • le test de régression de pltcl doit créer un opclass, et non juste un opérateur ;
  • le support d'ORDER BY ... NULLS FIRST/LAST et l'ajout des options par colonne de ASC/DESC/NULLS FIRST/NULLS LAST pour les index btree. Le support du planificateur pour ceux-ci est toujours rudimentaire ; il ne sait toujours pas comment planifier les jointures-fusion qui n'utilisent pas les options de tri par défaut. La documentation est tout aussi rudimentaire. Je travaillerai à son amélioration plus tard. Une modification incompatible est notée : ORDER BY ... USING sera maintenant rejetée si l'opérateur n'est pas un membre supérieur ou inférieur d'une classe d'opérateur btree. Cela permet d'éviter unn comportement dangereux si un opérateur qui ne définit un ordre de tri adéquat est sélectionné ;
  • la modification de la création des listes de jointures pour éviter la génération de sous-problèmes à un élément inutiles lorsque la construction des arbres JOIN est stoppée par join_collapse_limit. Par exemple, une liste de 11 LEFT JOIN avec une limite de 8 produit quelque chose comme ((1 2 3 4 5 6 7 8) 9 10 11 12) et non (((1 2 3 4 5 6 7 8) (9)) 10 11 12). Cette dernière n'étant réellement nécessaire que dans le cas d'un FULL JOIN. Relevé lors de l'étude d'un exemple de Shane Ambler ;
  • la suppression d'un très vieux hack de cost_hashjoin pour décourager (avant d'interdire complètement) les jointures de hachage dont la relation estimée la plus large est interne. Il y a de nombreux cas où cela à un sens, et dans le cas où cela n'en a pas, le calcul du coût doit en tenir compte. Diverses modifications on été réalisées sur ce calcul pour essayer d'obtenir des résultats approchant mieux la réalité. D'après un exemple de Shane Ambler. Le correctif original a également été corrigé pour ajouter seq_page_cost : les coûts de décomposition d'une jointure de hachage doivent être proportionnels à seq_page_cost.

D'Arcy Cain a commité :

  • l'élargissement du type money à 64 octets.

Peter Eisentraut a commité :

  • la correction de la compilation des expressions IS DOCUMENT ;
  • l'ajout du support des expressions xmlval IS DOCUMENT ;
  • la correction des avertissements de compilation dans pgsql/src/backend/parser/parse_expr.c ;
  • l'utilisation des échappements XML dans XMLFOREST ;
  • l'autorisation des types de données arbitraires comme contenu de XMLELEMENT. Le transtypage original vers le type xml était une erreur. Les valeurs sont échappées pour devenir des caractères XML valides. ;
  • l'utilisation de l'API xmlwriter de la libxml pour produire des éléments XML, plutôt que de réaliser notre propre gestion d'impression. Le résultat de mise entre guillemets et d'échappement des valeurs est meilleur ;
  • l'interdiction des noms d'attribut dupliqués dans XMLELEMENT ;
  • de l'optimisation de xmlpi dans les coins : correction des codes d'erreur, vérifications de syntaxe dans le bon ordre et suppression des espaces en début d'argument ;
  • la vérification et la documentation de la version minimale de libxml requise ;

Correctifs rejetés (à ce jour)

Pas de déception cette semaine.

Correctifs en attente

  • Simon Riggs a envoyé deux versions d'un correctif qui autorise à éviter d'écrire les WAL lors d'un COPY à l'intérieur d'une transaction explicite ;
  • Gurjeet Singh a envoyé une nouvelle révision de son correctif de l'Index Advisor ;
  • Dave Page a envoyé un correctif qui permet à pg_dumpall de sauvegarder les rôles et les tablespaces ;
  • Pavel Stehule a envoyé un correctif qui ajoute le support de parcours des curseurs à SPI.

© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.