LOXODATA

PostgreSQL 10.2 et autres correctifs

2018-02-12   961 mots, 5 minutes de lecture

PostgreSQL 10.2, 9.6.7, 9.5.11, 9.4.16, et 9.3.21 sont sortis !

Le PGDG publie un ensemble de correctifs. Il s’agit d’une mise à jour cumulative pour toutes les versions actuellement supportées de PostgreSQL. Celle-ci inclut les versions 10.2, 9.6.7, 9.5.11, 9.4.16, 9.3.21.

Cette publication corrige 2 failles de sécurité. Elle corrige également des bugs avec VACUUM, les index GIN et les index hash qui peuvent entrainer des corruptions de données. Il y a également des correctifs sur la parallélisation de requêtes et la réplication logique.

Tous les utilisateurs sont invités à procéder aux mises à jour dès que possible.

On se référera aux notes de « Mise à jour » plus bas pour les étapes postérieures à la migration qui pourraient être requises.

Le projet PostgreSQL a procédé à un changement de versionnement avec la publication de la version 10. Passer de 10.0, ou 10.1, à 10.2 est donc considéré comme une mise-à-jour mineure.

Failles de sécurité :

Deux vulnérabilités ont été corrigées par cette publication :

  • CVE-2018-1052 : Corrige le traitement des clés de partitionnement contenant des expressions multiples
  • CVE-2018-1053 : Assure que les fichiers temporaires créés avec “pg_upgrade” ne sont pas lisibles pas les autres utilisateurs

Correction de bugs et améliorations

Cette mise à jour corrige plus de 60 bugs rapportés dans les derniers mois. Certains affectent uniquement la version 10, mais beaucoup affectent toutes les versions supportées :

  • Corrige le crash et la divulgation potentielle de la mémoire de connexion lors du traitement de clés de partitions contenant des expressions multiples ;
  • Corrige la divulgation potentielle des fichiers temporaires contenant les mots de passe d’accès à la base de données créés par pg_upgrade en interdisant leur lecture par les autres utilisateurs UNIX ;
  • Corrige les cas où le VACUUM ne retire pas les lignes mortes, si les lignes ont été mises à jour alors qu’un verrou de type “key-share” était posé, conduisant à une potentielle corruption ;
  • Corrige les index GIN pour éviter le bloat en s’assurant que la liste des insertions en attente est nettoyée par VACUUM ;
  • Corrige une corruption éventuelle d’index hash due à l’échec du marquage des métapages comme dirty ;
  • Corrige plusieurs scenarios potentiels de crash pour les requêtes parallèles, dont les cas où un “bitmap heap scan” ne peut allouer de mémoire ;
  • Corrige plusieurs bloquages dans les requêtes parallèles, dont le cas où le worker de parallélisation échoue à démarrer ;
  • Corrige la collecte des statistiques EXPLAIN par les workers de parallélisation ;
  • Empêche les faux verrous mortels (deadlock) lorsque plusieurs sessions lancent CREATE INDEX CONCURRENTLY ;
  • Corrige le comportement des déclencheurs (triggers) en réplication logique ;
  • Plusieurs correctifs pour la fonctionnalité walsender pour améliorer la stabilité et la visibilité dans le processus de réplication ;
  • Corrige le décodage logique pour nettoyer correctement les fichiers sur disques lors de crash de transactions ;
  • Plusieurs correctifs sur les identity columns, dont leur interdiction sur les tables dérivées de types composites et partitions ;
  • Corrige la gestion des contraintes de partitionnement de liste pour les clés de partitions de type booléen ou tableau ;
  • Corrige la génération incorrecte de plans pour UPDATE et DELETE quand une table possède un mélange de tables héritées normales et étrangères ;
  • Corrige des résultats de requêtes incorrects dans les cas concernant GROUPING SETS lorsque utilisé avec des sous-requêtes désimbriquées ;
  • Corrige UNION/INTERSECT/EXCEPT sur des requêtes sans colonne, e.g. “SELECT UNION SELECT” ;
  • Contient plusieurs correctifs pour les sous-requêtes dans une sous-requête LATERAL ;
  • Contient plusieurs améliorations pour les estimations de plans de requêtes ;
  • Autorise un client supportant la liaison de canal SCRAM, comme une future version de PostgreSQL ou la libpq, à se connecter à un serveur PostgreSQL 10 ;
  • Corrige l’exemple de fonction INSTR() utilisée pour aider la transition d’Oracle ® PL/SQL vers PostgreSQL PL/pgSQL pour qu’il corresponde au comportement fonctionnel d’ORACLE ;
  • Corrige pg_dump pour rendre les permissions (ACL), le libellé de sécurité et les entrées de commentaires identifiables de façon fiable dans les sorties archives ;
  • Modifie le comportement de l’opérateur de la contrib/cube “cube~>int” pour le rendre compatible avec les recherches KNN. Ce changement interdit tout retour arrière, ainsi les index sur expression et les vues matérialisées utilisant cet opérateur nécessitent respectivement un REINDEX ou un REFRESH ;
  • Contient plusieurs correctifs de la contrib/postgres_fdw pour éviter les erreurs du planificateur de requêtes ;
  • Ajout d’exemples modernes de script d’auto-démarrage pour PostgreSQL sur macOS dans le répertoire contrib/start-scripts/macos ;
  • Contient plusieurs correctifs pour Windows, dont le démarrage du postmaster et la compatibilité avec libperl ;
  • Correctifs de spinlocks et support des architectures Motorola 68K et 88K.

Cette mise à jour contient également la publication 2018c pour tzdata, avec des mises à jour au sujet des nouvelles lois sur les changements d’heure (DST) pour le Brésil, Sao Tome et Principe, plus des correctifs pour la Bolivie, le Japon et le Soudan du Sud. La zone US/Pacific-New a été supprimée (celle-ci était un alias pour “America/Los_Angeles”).

Mise à jour

Toutes les mises à jour PostgreSQL sont cumulatives. Comme pour toute mise à jour mineure, il n’est pas utile de faire de dump/reload des bases de données ou d’utiliser pg_upgrade pour l’appliquer. Un simple arret de PostgreSQL et le remplaçement des binaires suffit.

Dans certains cas, des étapes post-mise à jour peuvent être nécessaires :

  • Les utilisateurs affectés par les problèmes d’index GIN et hash devront reconstruire ces index ;
  • Les utilisateurs ayant copié l’exemple “INSTR” issu de la documentation devront analyser leur code pour déterminer s’ils doivent ou non appliquer l’exemple corrigé de “INSTR” ;
  • Les utilisateurs qui utilisent l’opérateur “~>” trouvé dans “contrib/cube” avec des index d’expression ou des vues matérialisées devront effectuer respectivement un REINDEX ou un REFRESH. Ce changement empêchant tout retour arrière, il est préférable de tester cet opérateur avant tout déploiement en environnement de production.

Dans le cas où des mises à jours mineures ont été omises, il pourrait s’avérer nécessaire d’effectuer des étapes supplémentaires. Veuillez vous référer aux notes de versions précédentes pour les détails.