Sortie de PostgreSQL 14.3, 13.7, 12.11, 11.16 et 10.21

Publié le 13/05/2022 par David Bidoc, Benoit Lobréau, Christophe Courtois, Nicolas Gollet, Robin Portigliatti, Franck Boudehen, Florent Jardin, Laura Ricci

Paris, le 12 mai 2022

Le PostgreSQL Global Development Group a publié une mise à jour pour toutes les versions supportées de PostgreSQL, soit les versions 14.3, 13.7, 12.11, 11.16 et 10.21. Cette version corrige plus de 50 bugs signalés au cours des trois derniers mois. Voici notre traduction.

visuel annonce

Vous êtes encouragé à installer cette mise à jour dès que possible.

ATTENTION : Si vous avez des index GiST sur des colonnes qui utilisent le type ltree, vous devrez effectuer un REINDEX des champs concernés après la mise à jour.

Avertissement sur la fin de vie de PostgreSQL 10

PostgreSQL 10 ne recevra plus de correctifs après le 10 novembre 2022. Si vous utilisez PostgreSQL 10 en production, nous vous suggérons de planifier une mise à jour vers une version plus récente et supportée de PostgreSQL. Voir notre politique de versionnement pour plus d’informations.

Problème de sécurité

  • CVE-2022-1552: Autovacuum, REINDEX et d’autres négligent le bac à sable pour les opérations à sécurité restreinte.

Versions concernées : 10 à 14. L’équipe de sécurité ne teste habituellement pas les versions non supportées, mais ce problème est ancien. Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER et pg_amcheck ne cherchent pas totalement à opérer de manière sécurisée quand un utilisateur privilégié manipule les objets d’un autre utilisateur. Ces commandes n’utilisent les protections nécessaires que trop tard ou pas du tout. Un attaquant avec la permission de créer des objets non temporaires dans au moins un schéma peut exécuter des fonctions SQL arbitraires sous l’identité du superutilisateur.

La meilleure manière de corriger cela pour la plupart des utilisateurs est de mettre à jour PostgreSQL rapidement, mais un utilisateur qui ne peut se le permettre peut contourner la vulnérabilité en désactivant l’autovacuum, en ne lançant pas manuellement ces commandes, et en ne restaurant pas depuis la sortie de pg_dump. Les performances peuvent se dégrader rapidement suite à ce contournement. VACUUM est sûr, et toutes les commandes fonctionnent bien quand un utilisateur de confiance possède les objets concernés.

Le projet PostgreSQL remercie Alexander Lakhin pour avoir remonté ce problème.

Corrections de bugs et améliorations

Cette mise à jour corrige 50 bugs rapportés ces derniers mois. Les problèmes ci-dessous concernent PostgreSQL 14. Certains peuvent concerner d’autres versions supportées.

Sont inclues dans cette mise à jour :

  • Correction d’un problème menant à une corruption des index GiST sur des colonnes de type ltree. Ces index devront être reconstruits après la mise à jour
  • Les noms de colonnes produits par une variable de type ligne (comme tbl.*), en-dehors du plus haut niveau d’un SELECT, sont à présent toujours associés à ceux du type composite associé, s’il y en a un. Les notes de version détaillent une solution de contournement si dépendez de l’ancien comportement.
  • Correction d’une erreur d’arrondi lorsque l’on extrait l’epoch depuis des intervalles.
  • Correction d’un fonctionnement anormal à l’appel de pg_stat_get_replication_slot(NULL).
  • Correction d’une sortie incorrecte dans table_to_xmlschema() pour les types timestamptz et timetz.
  • Correction des erreurs liées à un problème du planificateur affectant les requêtes distantes asynchrones.
  • Correction d’une erreur du planificateur si une requête utilisant SEARCH ou CYCLE contient deux CTE (clause WITH) de même nom.
  • Correction d’ALTER FUNCTION pour permettre de modifier dans la même commande le parallélisme et les variables SET d’une fonction.
  • Correction d’un tri incorrect des lignes de tables lors d’un CLUSTER sur un index dont la clé contient une expression.
  • Correction d’une perte de données si un système crashe peu après la construction d’un index GiST avec la méthode par tri.
  • Correction d’un risque de « verrou mortel » (deadlock) à la suppression d’un index partitionné.
  • Correction d’une condition de concurrence (race condition) entre DROP TABLESPACE et le processus de checkpoint provoquant l’oubli de la suppression de tous les fichiers morts du tablespace.
  • Correction d’un problème potentiel lors de la reprise sur arrêt brutal après une commande TRUNCATE en même temps qu’un checkpoint.
  • Réautorisation de « _ » comme premier caractère d’un paramètre de configuration personnalisé.
  • Correction de l’erreur « PANIC: xlog flush request […] is not satisfied » durant la promotion d’un secondaire (standby), quand il manque un enregistrement de suivi dans les journaux de transaction.
  • Correction de la possibilité d’auto-deadlock dans la gestion des conflits avec un hot standby.
  • Assurance que les workers d’application de la réplication logique peuvent être redémarrés lorsque le serveur est proche de la limite max_sync_workers_per_subscription.
  • Interdiction de l’exécution des fonctions SPI durant la compilation des fonctions PL/Perl.
  • La libpq accepte désormais les fichiers de clés privées SSL appartenant à root, ce qui correspond aux règles utilisées par le serveur depuis la version 9.6.
  • Ré-autorisation du nommage par database.schema.table dans psql, pg_dump et pg_amcheck.
  • Plusieurs corrections pour pageinspect afin d’améliorer la stabilité globale.
  • Désactivation des insertions par lots dans postgres_fdw lorsque les triggers BEFORE INSERT … FOR EACH ROW existent sur la table distante.
  • Mise à jour du code JIT pour fonctionner avec LLVM 14.

Cette mise à jour contient également la release tzdata 2022a concernant les modifications de réglementation sur l’heure d’été en Palestine, ainsi que des corrections historiques pour le Chili et l’Ukraine. Pour la liste complète des changements, veuillez consulter les notes de mise à jour.

Mise à jour

Toutes les versions mineures de PostgreSQL sont cumulatives. Comme pour les autres versions mineures, les utilisateurs n’ont pas besoin d’exporter et restaurer leur base de données ou d’utiliser pg_upgrade pour mettre à jour vers cette version ; il suffit d’arrêter PostgreSQL et de mettre à jour ses binaires.

Cependant, si vous avez des index GIST sur des colonnes utilisant le type de données ltree, vous devrez les réindexer après la mise à jour.

Les utilisateurs qui ont sauté une ou plusieurs mises à jour peuvent avoir besoin d’exécuter des étapes supplémentaires après la mise à jour ; veuillez consulter les notes de mise à jour des versions précédentes pour plus de détails.

Pour accéder à la liste de toutes les modifications, veuillez consulter les notes de mise à jour.

Liens

DALIBO

DALIBO est le spécialiste français de PostgreSQL®. Nous proposons du support, de la formation et du conseil depuis 2005.