E.49. Sortie 7.4.2

Une sauvegarde restauration n'est pas requise pour ceux utilisant une version 7.4.X. Néanmoins, c'est la méthode conseillé car plus simple pour l'incorporation de la correction sur deux erreurs trouvées dans le contenu initial des catalogues systèmes de la 7.4. Une séquence sauvegarde/initdb/restauration utilisant l'initdb de la 7.4.2 corrigera automatiquement ces problèmes.

La plus sévère des deux erreurs est que le type de données anyarray a un mauvais label d'alignement ; ceci est un problème parce que le catalogue système pg_statistic utilise des colonnes anyarray. Ce mauvais label peut causer des mauvaises estimations du planificateur et même des arrêts brutaux lorsque des requêtes de planification impliquent des clauses WHERE sur des colonnes doublement alignées doubles (telles que float8 et timestamp). Il est fortement recommandé que toutes les installations réparent cette erreur, soit par initdb soit en suivant la procédure de réparation manuelle donnée ci-dessous.

L'erreur moindre est que la vue système pg_settings devrait être marquée comme ayant un accès public en mise à jour pour permettre l'utilisation de UPDATE pg_settings comme substitut pour SET . Ceci peut être corrigé soit par initdb soit manuellement mais il n'est pas nécessaire de le corriger sauf si vous voulez utiliser UPDATE pg_settings.

Si vous ne souhaitez pas lancer un initdb, la procédure suivante corrigera pg_statistic. En tant que superutilisateur de la base de données, faites :

-- efface les anciennes données de pg_statistic :
DELETE FROM pg_statistic;
VACUUM pg_statistic;
-- ceci devrait mettre à jour 1 ligne :
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- ceci devrait mettre à jour 6 lignes :
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
--     
-- À ce moment, vous DEVEZ lancer un nouveau moteur pour éviter un arrêt brutal
--
-- repopulate pg_statistic:
ANALYZE;

Ceci peut se faire sur une base de données en réel mais attention au fait que tous les serveurs de la base de données modifiée doivent être relancés avant qu'il ne soit sain de repeupler pg_statistic.

Pour corriger l'erreur pg_settings, faites simplement :

GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;

Les procédures ci-dessus doivent être exécutées dans chaque base de données d'une installation, ceci incluant template1, et idéalement template0. Si vous ne corrigez pas les bases de données modèles, alors toute nouvelle base de données contiendra les mêmes erreurs. template1 peut être corrigé de la même façon que toute autre base de données, mais corriger template0 requiert quelques étapes supplémentaires. Tout d'abord, à partir de n'importe quelle session de base de données

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

nsuite, connectez-vous à template0 et exécutez les procédures de réparation suivante. Enfin, faites

-- re-gèle template0:
VACUUM FREEZE;
-- et la protège contre toute modifications futures :
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

La version 7.4.2 incorpore toutes les corrections de la version 7.3.6, ainsi que les suivantes :