Mises à jour mineures de PostgreSQL : 9.2.2, 9.1.7, 9.0.11, 8.4.15, 8.3.22

Le projet PostgreSQL sort aujourd'hui des mises à jour pour toutes les branches actives du SGBD PostgreSQL. Celles-ci correspondent aux versions 9.2.2, 9.1.7, 9.0.11, 8.4.15 et 8.3.22. Les utilisateurs de la réplication avec un esclave en lecture seule doivent appliquer cette mise à jour dès que possible. Les autres utilisateurs devraient planifier la mise à jour lors de la prochaine interruption de service programmée.

Ces nouvelles versions corrigent un problème d'ordonnancement des pages d'index sur les esclaves en lecture seule (Hot Standby) qui peuvent entrainer des corruptions des index sur les esclaves. De plus, cette mise à jour corrige également un problème d'ordonnancement entre le CHECKPOINT et le rebouclage des identifiants de transactions. Enfin, de nombreux problèmes avec CREATE INDEX CONCURRENTLY et DROP INDEX CONCURRENTLY sont corrigés. Ces problèmes pouvaient amener l'échec de la création des index, entraînant ainsi la corruption de ces index. Les utilisateurs de ces fonctionnalités sont invités à effectuer un REINDEX ou à recréer les index concernés (voir plus loin).

Cette mise à jour contient également des correctifs pour de nombreux problèmes mineurs découverts et corrigés par la communauté PostgreSQL durant le dernier mois, incluant de nombreuses corrections pour la dernière version 9.2. Cela inclue :

  • le correctif d'un crash de psql lorsqu'il rencontre des données mal encodée ;
  • le correctif d'un problème de construction de pg_regress avec gmake ;
  • le correctif pour s'assurer que le répertoire approprié est créé pour les extensions ;
  • le correctif de plusieurs problèmes de verrouillage avec VACUUM ;
  • le correctif de plusieurs problèmes et quelques amélioration de pg_upgrade ;
  • le correctif de bugs d'arrêt de la restauration en cas de fail-over sur un esclave ;
  • le correctif d'un problème d'identifiant de timeline dans le mode standby ;
  • un correctif pour empêcher le lancement de processus enfants au moment de l'arrêt du serveur ;
  • l'amélioration du planificateur pour utiliser des index partiels sur des jointures ;
  • le correctif de problèmes de dépassement de capacité des types entier sur certaines architectures ;
  • le correctif de fuites mémoire dans record_out() et record_send() ;
  • une amélioration pour éviter la recherche des verrous de sous-transactions au moment du COMMIT ;
  • le correctif de problèmes liés à WaitLatch() ;
  • le correctif de la gestion des contraintes CHECK héritées dans ALTER COLUMN TYPE ;
  • le correctif de ALTER EXTENSION SET SCHEMA pour que cette instruction se comporte comme documenté ;
  • le déplacement des ordres ALTER SEQUENCE SET dans la section “données” (data) des exports de sections ;
  • le correctif de l'analyseur pour lui indiquer que les vues n'ont pas de colonnes systèmes ;
  • le correctif de la fonctionnalité –clean de pg_dump ;
  • le correctif d'un problème de corruption des tables de hachages de l'exécuteur en cas de manque de mémoire ;
  • plusieurs correctifs et améliorations du planificateur et de l'exécuteur ;
  • plusieurs mises à jour de la documentation ;
  • le changement des données de fuseau horaire pour 7 fuseaux horaires.

Par ailleurs, l'arrêt du support de la branche 8.3 est annoncé pour février 2013. Si ce n'est pas déjà fait, il est temps de penser à migrer vers une version plus récente. Pour de plus amples informations, se référer à la politique de suivi des versions du projet PostgreSQL.

Comme pour toutes les versions mineures, vous pouvez appliquer cette mise à jour avec un simple arrêt de PostgreSQL suivi d'une mise à jour des exécutables et bibliothèques, et de redémarrer PostgreSQL. Les utilisateurs faisant une mise à jour entre des versions majeures différentes devront faire une sauvegarde et une restauration de leurs bases de données ou utiliser pg_upgrade. Les utilisateurs de versions plus anciennes qui ont sauté plusieurs mises à jour auront peut-être à effectuer d'autres actions suite à la mise à jour ; voir les notes de version de chaque version mineure pour plus de détails.

À l'issue de la mise à jour, les utilisateurs ayant utilisé CREATE INDEX CONCURRENTLY sont invités à exécuter un REINDEX ou à supprimer et recréer les index qui ont été créé avec CREATE INDEX CONCURRENTLY. De cette façon, l'intégrité des index sera garantie. Malheureusement, il n'est pas possible de distinguer les index créés de manière concurrente de ceux créés de manière non-concurrente, les utilisateurs devront donc s'appuyer sur les connaissances de leurs administrateurs de bases de données. Une fois la mise à jour appliquée, les utilisateurs pourront créer les nouveaux index de manière concurrente et supprimés les anciens également de manière concurrente pour minimiser l'indisponibilité de la base de données.

Afficher le texte source