Des mises à jour correctives ont été générées pour toutes les branches supportées de PostgreSQL : 14.2, 13.6, 12.10, 11.15 et 10.20, qui corrigent 55 erreurs identifiées au cours des trois derniers mois. Entre autres choses, nous avons résolu des problèmes qui, dans de rares circonstances, entraînaient une corruption d'index lors de la modification de chaînes HOT (tuple tas uniquement) lors d'une opération VACUUM ou lors de l'exécution d'une opération REINDEX CONCURRENTLY sur les index des tables qui utilisent le mécanisme de stockage TOAST.
Correction de crashs lors de l'exécution d'ALTER STATISTICS et lors de la récupération de données avec des types multi-plage. Les bogues dans le planificateur de requêtes qui provoquaient des résultats incorrects ont été corrigés. Correction de fuites de mémoire lors de la mise à jour d'index à l'aide d'expressions et lors de l'exécution d'une opération REASSIGN OWNED BY sur un grand nombre d'objets. La construction de statistiques avancées pour les tableaux segmentés est fournie.
De plus, on peut noter la sortie de l'utilitaire reshape, qui vous permet d'effectuer des mises à jour complexes du schéma de données dans PostgreSQL sans arrêter le travail, ce qui, dans des conditions normales, nécessite des modifications manuelles et un arrêt temporaire des services utilisant la base de données. L'utilitaire permet de passer de l'ancien schéma de données au nouveau sans blocage prolongé et sans interrompre le cycle de traitement des requêtes. L'utilitaire crée automatiquement des vues de table avec lesquelles les applications continuent de travailler pendant la migration des schémas de données, et configure également des déclencheurs qui traduisent les opérations d'ajout et de suppression de données entre l'ancien et le nouveau schéma.
Ainsi, lors de l'utilisation de reshape lors de la migration, l'ancien et le nouveau schéma restent disponibles en même temps et les applications peuvent être progressivement transférées vers le nouveau schéma sans arrêter le travail (dans les grandes infrastructures, les gestionnaires peuvent être progressivement remplacés de l'ancien au nouveau). Une fois la migration des applications vers le nouveau schéma terminée, les vues et les déclencheurs créés pour maintenir la prise en charge de l'ancien schéma sont supprimés. Si des problèmes avec les applications sont identifiés lors de la migration, vous pouvez annuler la modification du schéma et revenir à l'ancien état.
Source: opennet.ru