{"id":103298,"date":"2022-02-11T15:36:48","date_gmt":"2022-02-11T13:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty"},"modified":"2022-02-11T15:36:48","modified_gmt":"2022-02-11T13:36:48","slug":"obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty","title":{"rendered":"Mise \u00e0 jour de PostgreSQL. Publication de reshape, un utilitaire pour la migration vers un nouveau sch\u00e9ma sans interrompre le service.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des mises \u00e0 jour correctives ont \u00e9t\u00e9 publi\u00e9es pour toutes les versions prises en charge de PostgreSQL : 14.2, 13.6, 12.10, 11.15 et 10.20, corrigeant 55 erreurs d\u00e9tect\u00e9es au cours des trois derniers mois. Parmi celles-ci, des probl\u00e8mes ayant conduit \u00e0 une corruption des index dans des circonstances rares lors de la modification de cha\u00eenes HOT (heap-only tuple) pendant l'ex\u00e9cution de l'op\u00e9ration VACUUM ou lors de l'ex\u00e9cution de l'op\u00e9ration REINDEX CONCURRENTLY pour les index des tables utilisant le m\u00e9canisme de stockage TOAST ont \u00e9t\u00e9 r\u00e9solus. <\/p>\n
Les erreurs de terminaison impr\u00e9vue lors de l'ex\u00e9cution d'ALTER STATISTICS et lors de l'extraction de donn\u00e9es avec des types multirange ont \u00e9t\u00e9 corrig\u00e9es. Dans le planificateur de requ\u00eates, les erreurs qui entra\u00eenaient l'affichage de r\u00e9sultats incorrects ont \u00e9t\u00e9 \u00e9limin\u00e9es. Des fuites de m\u00e9moire ont \u00e9t\u00e9 r\u00e9solues lors de la mise \u00e0 jour des index bas\u00e9s sur des expressions et lors de l'ex\u00e9cution de l'op\u00e9ration \u00ab REASSIGN OWNED BY \u00bb sur un grand nombre d'objets. La construction de statistiques avanc\u00e9es pour les tables segment\u00e9es a \u00e9t\u00e9 assur\u00e9e. <\/p>\n
On peut \u00e9galement noter la sortie de l'utilitaire reshape, permettant d'effectuer des mises \u00e0 jour complexes du sch\u00e9ma de donn\u00e9es dans PostgreSQL sans interruption du service, ce qui n\u00e9cessiterait normalement des modifications manuelles et l'arr\u00eat temporaire des services utilisant la base de donn\u00e9es. Cet utilitaire permet de passer de l'ancien sch\u00e9ma de donn\u00e9es au nouveau sans longues p\u00e9riodes de blocage et sans interrompre le cycle de traitement des requ\u00eates. L'utilitaire cr\u00e9e automatiquement des vues des tables avec lesquelles les applications continuent de travailler pendant la migration du sch\u00e9ma de donn\u00e9es, et configure \u00e9galement des triggers pour transmettre les op\u00e9rations d'ajout et de suppression de donn\u00e9es entre l'ancien et le nouveau sch\u00e9ma. <\/p>\n
Ainsi, lors de l'utilisation de reshape pendant la migration, l'ancien et le nouveau sch\u00e9ma restent accessibles en m\u00eame temps, permettant aux applications de passer progressivement au nouveau sch\u00e9ma sans interruption du travail (dans les grandes infrastructures, les gestionnaires peuvent \u00eatre remplac\u00e9s progressivement de l'ancien au nouveau). Une fois que le transfert des applications vers le nouveau sch\u00e9ma est termin\u00e9, les vues et les d\u00e9clencheurs cr\u00e9\u00e9s pour maintenir la prise en charge de l'ancien sch\u00e9ma sont supprim\u00e9s. En cas de probl\u00e8mes avec les applications pendant la migration, il est possible d'annuler le changement de sch\u00e9ma et de revenir \u00e0 l'ancien \u00e9tat. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"