Avant la fin du support de PostgreSQL 14 en 2026, comment vérifier la compatibilité des extensions ?

La page officielle de support fixe au 12 novembre 2026 la fin des mises à jour de PostgreSQL 14 : vérifiez la date dans le calendrier de support des versions PostgreSQL. La décision opérationnelle est simple : ne lancez pas la bascule tant que vous n’avez pas vérifié, pour chaque extension, les fichiers disponibles et le chemin de mise à jour sur la cible, puis testé les fonctions réellement utilisées par l’application dans un environnement isolé. Si cette validation n’est pas achevée avant l’échéance, ne poussez pas une mise à niveau non répétée directement en production.

Cet article s’adresse aux DBA qui doivent recenser les extensions et vérifier les prérequis de mise à niveau.
Il aide les ingénieurs logiciels à confirmer que les fonctions appelées par l’application restent utilisables.
Il s’adresse aussi aux responsables techniques qui doivent décider si une répétition complète est réalisable avant la bascule.

Dernière mise à jour : 28 octobre 2026. La date de fin de support et les informations de version sont vérifiées à partir des sources officielles PostgreSQL sur le support et la publication de la branche 14. Les informations sur les extensions restent à confirmer auprès de la documentation et du paquet de chaque extension.

Extension absente ou simplement non recensée : commencez par l’inventaire

Avant de déduire qu’une extension n’est pas utilisée, distinguez trois réalités : celles qui sont installées dans une base, celles que l’installation cible peut proposer et celles dont l’application dépend effectivement. Un résultat vide dans une seule base ne prouve donc pas l’absence de dépendances dans toute l’instance.

Connectez-vous à chaque base de données de l’instance et relevez les extensions installées. La vue système pg_extension expose notamment le nom et la version installée ; sa documentation décrit ces colonnes et leur rôle dans le catalogue PostgreSQL.

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Cette requête fournit un inventaire des extensions installées dans la base où vous l’exécutez. Elle ne dresse pas à elle seule la liste des fonctions appelées par votre code, des extensions seulement disponibles, ni des dépendances présentes dans des scripts de déploiement. Pour comprendre le résultat, consultez la description officielle du catalogue pg_extension.

Sur l’environnement cible, vérifiez séparément les extensions proposées par l’installation :

SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;

La vue pg_available_extensions décrit les extensions disponibles dans l’installation PostgreSQL connectée ; elle n’atteste pas que celles-ci sont déjà installées dans votre base, ni que toutes les fonctions attendues par l’application sont opérationnelles. Ses colonnes sont détaillées dans la documentation officielle de cette vue.

Complétez ces requêtes par une recherche dans les migrations de schéma, les procédures de déploiement, les scripts d’administration et le code applicatif. Repérez notamment les types, fonctions, opérateurs et méthodes d’indexation propres aux extensions. Un nom trouvé dans un fichier ne prouve pas qu’il est encore utilisé, mais son absence dans le catalogue ne suffit pas à conclure que le code n’en dépend pas.

Même nom d’extension, mais fichiers ou versions incompatibles

Le fait que le même nom apparaisse dans l’instance actuelle et dans la cible ne démontre pas que la mise à niveau fonctionnera. L’extension doit être fournie pour l’environnement PostgreSQL cible, avec les fichiers nécessaires et une version compatible ; si elle requiert du code compilé, celui-ci doit correspondre à l’installation et à la plateforme de destination.

La documentation PostgreSQL sur le mécanisme des extensions explique qu’une extension s’appuie sur des fichiers de contrôle, des scripts SQL et, selon les cas, des bibliothèques. Vérifiez la provenance du paquet sur la cible et la matrice de compatibilité publiée par le mainteneur de l’extension. Ne généralisez pas une information trouvée pour une version ou une distribution à une autre installation.

Pour chaque élément de votre inventaire, consignez au minimum : la version installée, la version proposée sur la cible, la présence des fichiers requis, l’existence d’un chemin de mise à jour documenté et les fonctions de l’application concernées. Lorsqu’une installation propose plusieurs versions, comparez les versions explicitement plutôt que de vous fier seulement à la version par défaut.

PostgreSQL documente également la commande ALTER EXTENSION ... UPDATE, qui applique un script de mise à jour lorsqu’un chemin adapté est fourni. Vous pouvez interroger les chemins proposés pour une extension donnée :

SELECT source, target, path
FROM pg_extension_update_paths('nom_extension')
ORDER BY source, target;

Un chemin affiché est un élément de vérification, pas une preuve de bon fonctionnement applicatif. À l’inverse, l’absence de chemin directement exploitable peut imposer une mise à jour intermédiaire, une modification de dépendance ou une stratégie propre au mainteneur. La référence PostgreSQL de ALTER EXTENSION précise le comportement de la commande ; vérifiez aussi les instructions de la version de l’extension utilisée.

Quand l’extension bloque la vérification, séparez les causes

Un contrôle de mise à niveau peut signaler plusieurs catégories de problème. Traitez-les une par une : fichiers manquants sur la cible, version installée sans chemin de mise à jour, bibliothèque introuvable, ou objets de la base qui dépendent de l’extension. Ne supprimez pas une extension uniquement pour faire disparaître un avertissement.

Pour isoler un blocage, conservez la sortie complète des vérifications et les journaux, puis rapprochez-les de l’inventaire par base. Si le message indique une bibliothèque absente, contrôlez d’abord la présence du paquet et des fichiers nécessaires sur la cible. Si le chemin de mise à jour manque, vérifiez les versions proposées et la procédure du mainteneur. Si des objets dépendent de l’extension, identifiez leur fonction avant toute modification.

La documentation de pg_upgrade décrit les vérifications de compatibilité et les options de contrôle à effectuer avant la mise à niveau. Exécutez l’outil avec les répertoires et binaires correspondant aux deux installations, dans une copie de votre environnement, en mode de vérification :

pg_upgrade --check \
  --old-bindir=/chemin/anciens-binaires \
  --new-bindir=/chemin/nouveaux-binaires \
  --old-datadir=/chemin/ancien-repertoire \
  --new-datadir=/chemin/nouveau-repertoire

Les chemins ci-dessus sont des valeurs à remplacer, pas des répertoires universels. La procédure et les options doivent être vérifiées dans la documentation officielle de pg_upgrade pour PostgreSQL 17, ou dans la documentation de la version cible effectivement retenue. Un contrôle réussi ne remplace pas la validation des fonctions par l’application : l’outil ne peut pas démontrer que chaque parcours métier, requête ou tâche planifiée répond à vos attentes.

L’extension s’installe, mais l’application échoue : testez ses usages

L’installation et l’activation d’une extension ne constituent qu’un contrôle de chargement. Une validation utile reproduit les opérations réellement employées : création et interrogation des index concernés, appels de fonctions, traitements de données, tâches planifiées et opérations de maintenance. Si l’application utilise un connecteur ou une couche de migration, incluez-les dans la répétition.

Établissez une liste de tests à partir des usages observés et des dépendances trouvées dans le code, puis exécutez-les sur une copie isolée de la base avec les mêmes versions de l’application, des pilotes et des outils de déploiement que celles envisagées pour la production. Notez pour chaque test la version de PostgreSQL, la version de l’extension, la commande ou le parcours exécuté, le résultat obtenu et la méthode de retour arrière.

Après une réussite en environnement d’essai, testez aussi la procédure de sauvegarde et de restauration utilisée pour cet environnement. La documentation PostgreSQL consacrée à la sauvegarde et à la restauration décrit les approches disponibles ; choisissez celle qui convient à votre architecture et vérifiez que vous savez effectivement restaurer les données et les objets requis. Une sauvegarde non testée ne constitue pas un plan de retour arrière validé.

Si vous hésitez sur la décision, appliquez ces branches :

• Si les fichiers de l’extension existent sur la cible, qu’un chemin documenté est disponible et que les tests applicatifs passent sur une copie, alors vous pouvez préparer une bascule planifiée, après validation d’une restauration et du retour arrière.
• Si le nom est disponible, mais que les fichiers, la version ou le chemin de mise à jour restent incertains, alors bloquez la bascule et résolvez l’incertitude sur un environnement isolé.
• Si une fonction métier dépend d’une extension non disponible ou échoue pendant la répétition, alors choisissez et testez une autre cible ou une évolution de dépendance avant la production.
• Si la sauvegarde ne peut pas être restaurée selon la procédure prévue, alors ne considérez pas l’opération comme prête, même si pg_upgrade --check ne signale aucun blocage.

Vérifications de serveur et conditions de bascule

Une extension compatible ne suffit pas à rendre la migration sûre. Avant le changement de production, réunissez dans le même dossier de décision l’inventaire des extensions, les sorties de vérification, la répétition de mise à niveau, les résultats de tests applicatifs, la restauration validée et la procédure de retour arrière. La mise à niveau du répertoire de données, la reprise des écritures et la sauvegarde hors machine doivent être traitées comme des étapes d’un même plan.

Le choix d’un serveur dédié ne crée ni réplication ni redondance automatique. Dans l’offre OSFP Cloud, les configurations indiquées comprennent 128 Go ou 256 Go de mémoire DDR4 ECC, ainsi que deux SSD NVMe de 1 To raccordés directement, sans contrôleur RAID matériel. Ces éléments décrivent une base matérielle à vérifier par rapport à votre charge ; ils ne garantissent ni la compatibilité d’une extension ni la disponibilité continue des données. Pour organiser les volumes et examiner les possibilités de stockage, consultez aussi le guide OSFP Cloud sur la mémoire et les disques.

Vous devez prévoir vous-même la protection adaptée, par exemple un RAID logiciel ou une réplication selon votre architecture, et conserver les sauvegardes hors de la machine. Un miroir local ne remplace pas une copie externe : une erreur applicative, une suppression ou un incident affectant le serveur peut compromettre plusieurs copies locales simultanément.

Les systèmes proposés, l’espace disque réellement mobilisable, les besoins de mémoire, les contraintes des extensions et la méthode d’accès doivent être vérifiés pour l’environnement que vous déployez. L’accès aux systèmes Linux s’effectue par SSH ; les modalités sont décrites dans le guide OSFP Cloud consacré à l’accès SSH. Aucun de ces éléments ne signifie qu’OSFP Cloud installe vos extensions, administre PostgreSQL ou réalise la migration à votre place.

Si vous envisagez de remplacer une base gérée ou une machine partagée par un serveur dédié, comparez les responsabilités autant que les ressources : sur une offre partagée, la concurrence entre charges et les limites d’instances peuvent compliquer le contrôle des performances ; sur une base autogérée, vous assumez les mises à jour, les vérifications d’extensions, les sauvegardes et la restauration. OSFP Cloud peut être une option pertinente si votre équipe veut disposer d’une machine physique dédiée et sait prendre en charge cette exploitation. En revanche, pour une charge éphémère ou sans capacité d’administration PostgreSQL, une solution gérée peut rester plus appropriée.

Avant toute commande de production, terminez l’inventaire extension par extension, faites valider les usages applicatifs et répétez la restauration. La compatibilité PostgreSQL 14 des extensions n’est établie ni par leur seul nom ni par une vérification automatique : c’est l’accord entre les fichiers de la cible, leur chemin de mise à jour et vos tests qui doit décider de la bascule.