Mise à jour de PostgreSQL. Publication de reshape, un utilitaire pour la migration vers un nouveau schéma sans interrompre le service.

Des mises à jour correctives ont été publiées pour toutes les versions prises en charge de PostgreSQL : 14.2, 13.6, 12.10, 11.15 et 10.20, corrigeant 55 erreurs détectées au cours des trois derniers mois. Parmi celles-ci, des problèmes ayant conduit à une corruption des index dans des circonstances rares lors de la modification de chaînes HOT (heap-only tuple) pendant l'exécution de l'opération VACUUM ou lors de l'exécution de l'opération REINDEX CONCURRENTLY pour les index des tables utilisant le mécanisme de stockage TOAST ont été résolus.

Les plantages lors de l'exécution d'ALTER STATISTICS et lors de l'extraction de données avec des types multirange ont été corrigés. Dans le planificateur de requêtes, des erreurs conduisant à des résultats incorrects ont été éliminées. Des fuites de mémoire lors de la mise à jour des indexes par expressions et lors de l'exécution de l'opération «REASSIGN OWNED BY» sur un grand nombre d'objets ont été corrigées. La construction de statistiques avancées pour les tables segmentées a été assurée.

On peut également noter la sortie de l'utilitaire reshape, permettant d'effectuer des mises à jour complexes du schéma de données dans PostgreSQL sans interruption du service, ce qui nécessiterait normalement des modifications manuelles et l'arrêt temporaire des services utilisant la base de données. Cet utilitaire permet de passer de l'ancien schéma de données au nouveau sans longues périodes de blocage et sans interrompre le cycle de traitement des requêtes. L'utilitaire crée automatiquement des vues des tables avec lesquelles les applications continuent de travailler pendant la migration du schéma de données, et configure également des triggers pour transmettre 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 pendant la migration, l'ancien et le nouveau schéma restent accessibles en même temps, permettant aux applications de passer progressivement au nouveau schéma sans interruption du travail (dans les grandes infrastructures, les gestionnaires peuvent être remplacés progressivement de l'ancien au nouveau). Une fois que le transfert des applications vers le nouveau schéma est terminé, les vues et les déclencheurs créés pour maintenir la prise en charge de l'ancien schéma sont supprimés. En cas de problèmes avec les applications pendant la migration, il est possible d'annuler le changement de schéma et de revenir à l'ancien état.

Source : opennet.ru