LOXODATA

PostgreSQL 11.2 et autres correctifs

2019-02-14   1007 mots, 5 minutes de lecture

Le PGDG a publié un ensemble de correctifs. Il s’agit d’une mise à jour cumulative pour toutes les versions actuellement supportées de PostgreSQL.

Les versions publiées sont 11.2, 10.7, 9.6.12, 9.5.16 et 9.4.21.

Cette publication change le comportement de PostgreSQL vis-à-vis de fsync() et inclut des correctifs pour le partitionnement et 70 autres bugs rapportés ces 3 derniers mois.

Les utilisateurs sont encouragés à mettre à jour leurs serveurs lors de la prochaine maintenance planifiée.

Changement de comportement vis-à-vis de fsync()

Lorsque cette fonction est disponible pour le système d’exploitation, et qu’elle est activée dans le fichier de configuration (par défaut), PostgreSQL utilise la fonction fsync() du noyau pour écrire les données sur disque. Certains systèmes d’exploitation qui fournissent la fonction fsync() remontent une erreur et effacent les données qu’ils auraient dû écrire lorsqu’ils rencontrent un problème d’écriture sur disque.

Cette opération d’effacement des données a un malheureux effet secondaire pour PostgreSQL : si PostgreSQL essaie d’écrire les données sur disque en appelant à nouveau la fonction fsync(), fsync() va répondre que l’opération est un succès, mais les données que PostgreSQL pense avoir sauvegardées sur le disque ne seront pas réellement écrites. Il s’agit donc d’un cas possible de corruption de données.

Cette mise-à-jour modifie la façon dont PostgreSQL gère l’erreur de fsync(). PostgreSQL ne retente pas l’appel à fsync() mais sort en mode panic. Dans ce cas, PostgreSQL pourra rejouer les données depuis le fichier de WAL pour assurer l’écriture de ces données. Bien que cela puisse paraître une solution suboptimale, il n’y a pas, à ce jour, beaucoup d’autres alternatives, et, d’après les rapports reçus, ce cas n’arrive que très rarement.

Un nouveau paramètre data_sync_retry a été ajouté pour gérer ce fonctionnement. Dans le cas où il est certain que le noyau ne supprime pas les tampons de données invalides en cas d’erreur fsync() alors, le paramètre data_sync_retry peut être positionné à on pour restaurer le comportement précédent.

Améliorations et corrections de bugs

Cette mise à jour introduit un changement dans la manière de packager les release notes. À partir de ce correctif, toutes les versions supportées de PostgreSQL ne contiendront que les notes de versions correspondant à la version majeure concernée. Par exemple, PostgreSQL 11 ne comporte que les notes de version des versions 11.2, 11.1 et 11.0. Les release notes pour les versions non supportées (PostgreSQL 9.3 et inférieur) seront disponibles dans les anciennes versions et dans un archivage spécifique bientôt mis en place sur le site postgresql.org.

Cette mise à jour corrige également près de 70 bugs reportés ces derniers mois. Certains problèmes ne concernent que la version 11, mais beaucoup concernent toutes les versions supportées.

Ces correctifs comprennent (entre autres):

  • la correction de la gestion des index uniques avec la clause INCLUDE sur les tables partitionnées ;
  • l’assurance que les contraintes NOT NULL sur une table partitionnée sont vérifiées sur toutes ses partitions ;
  • plusieurs correctifs sur la gestion des contraintes des tables partitionnées ;
  • la correction de problèmes lors de la gestion de ON COMMIT DROP ou ON COMMIT DELETE ROWS sur des tables partitions et sur des tables avec héritage ;
  • l’interdiction de l’ordre COPY FREEZE sur des tables partitionnées ;
  • plusieurs correctifs pour l’utilisation de ALTER TABLE .. ADD COLUMN avec une valeur par défaut non null, y compris un cas possible de corruption d’index ;
  • plusieurs correctifs concernant les index GIN, y compris la correction d’un possible verrou mortel entre le process de vacuum et des insertions concurrentes dans l’index (ce qui entraîne une annulation partielle des améliorations de performances apportées en PostgreSQL 10) ;
  • la résolution d’un possible crash de la réplication logique quand des index partiels sont utilisés ;
  • plusieurs correctifs pour les write-ahead log (WAL) ;
  • la résolution d’un possible crash si un UPDATE est utilisé avec plusieurs clauses SET utilisant un sous-SELECT ;
  • la résolution d’un crash quand aucune ligne n’est retournée par json[b]_populate_recordset() ou json[b]_to_recordset() ;
  • plusieurs correctifs liés à la gestion des collations, incluant le parsing des expressions sensibles à la collation comme argument d’un appel CALL ;
  • plusieurs correctifs concernant le planificateur, y compris l’accélération de la planification pour un grand nombre de tables héritées ou partitionnées ;
  • plusieurs correctifs pour l’ordre TRUNCATE ;
  • l’assurance que ALTER TABLE ONLY ADD COLUMN IF NOT EXISTS est géré correctement ;
  • l’autorisation de la clause UNLISTEN en mode hot-standby (répliqua) ;
  • la résolution du problème de parsing des listes de nom d’hôtes séparés par des espaces dans ldapserver ;
  • plusieurs correctifs pour ecpg ;
  • plusieurs correctifs pour psql, y compris permettre \g target après COPY TO STDOUT ;
  • la génération de nombres aléatoires pour pgbench est maintenant entièrement déterministe et indépendante de la plateforme quand --random-seed=N est utilisé ;
  • pg_basebackup et pg_verify_checksums ignorent correctement les fichiers temporaires ;
  • plusieurs correctifs pour pg_dump, y compris l’ajout d’une clause ALTER INDEX SET STATISTICS si nécessaire ;
  • la prévention d’un faux rapport de corruption d’index par la contribution amcheck causée par des données compressées à la volée ;
  • le support de nouvelles variables pour le Makefile pour permettre la compilation des extensions.

Cette mise à jour contient également les informations de timezone pour les changements intervenus au Kazakhstan, au Metlakatla et à Sao Tomé et Principe en 2018. La zone Qyzylorda du Kazakhstan est coupée en 2, ce qui a entraîné la création d’une nouvelle zone nommée Asia/Qostanay, car certaines zones n’ont pas changé leur décalage avec UTC. Il y a eu également des corrections historiques pour Honk Kong et plusieurs îles du Pacifique.

Mise à jour

Toutes les mises à jour de 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 arrêt de PostgreSQL et le remplacement des binaires suffit.

Dans le cas où des mises à jour 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.

PostgreSQL 9.4 sera en fin de support le 13 février 2020. Veuillez lire notre politique de versioning pour plus d’informations.

Liens utiles