PostgreSQL : l’alerte de collation disparaît, le risque reste

Après une mise à jour du serveur, l’application redémarre et ses pages répondent. PostgreSQL signale pourtant un décalage de version de collation. Une commande trouvée rapidement fait disparaître l’avertissement ; la livraison est déclarée terminée. Quelques recherches métier restent ensuite incohérentes : un dossier existe, mais un parcours ne le retrouve plus. Le problème n’est pas nécessairement une ligne perdue ; une structure de recherche peut encore utiliser un ordre devenu incompatible.

La vraie question est de savoir si les objets dépendant de cet ordre ont été reconstruits et vérifiés. Mettre à jour la version enregistrée n’est pas cette reconstruction. Le diagnostic doit relier le fournisseur de collation, les objets concernés, les environnements qui les lisent et les résultats attendus par l’application, au lieu de prendre le silence du journal pour une preuve de correction.

Nous partons des références PostgreSQL 18, puis d’un exercice fictif à quatre libellés. Deux ordres explicites montrent comment une recherche dichotomique peut manquer une valeur pourtant présente. Les 23 contrôles s’exécutent localement en Python ; ils n’émulent pas ICU ou libc et ne reproduisent pas une mise à jour PostgreSQL réelle. La recette d’une installation garde donc son périmètre et ses preuves propres.

Ce travail relève du développement web sur mesure lorsqu’une application dépend de recherches, d’exports et de traitements backend. Un audit technique de l’application web doit examiner ces dépendances d’exploitation, même si le code PHP, Symfony ou JavaScript n’a pas changé pendant la mise à jour du système.

Pour qui : une application dont les lectures dépendent des collations

Reconnaître un changement sous le code applicatif

La documentation des collations explique qu’elles déterminent notamment l’ordre et la classification des caractères, au niveau des colonnes ou des opérations. Une requête peut utiliser la collation par défaut de la base ou une collation explicite. Le nom d’une colonne textuelle ne permet donc pas de connaître à lui seul la règle réellement employée.

Le sujet concerne un SaaS, un portail client ou un outil métier qui recherche des sociétés, trie des références ou exporte des populations ordonnées. Un changement d’image de conteneur, d’OS ou de bibliothèques peut modifier l’environnement de comparaison alors que la migration Doctrine ne contient aucun changement de schéma. La recette doit couvrir cette évolution sous-jacente, pas uniquement les fichiers du dernier déploiement applicatif.

Qualifier le symptôme sans annoncer une corruption générale

Un avertissement de version impose une analyse ; il ne prouve pas que chaque index produit déjà des résultats faux. Certains jeux de valeurs peuvent conserver le même ordre. À l’inverse, réussir trois recherches sur des références simples ne suffit pas à exclure un problème sur d’autres libellés. La priorité consiste à définir les objets et les parcours exposés, avec des témoins adaptés à leurs données.

Conservez les requêtes, paramètres, identifiants attendus et plans observés lorsque le résultat semble incohérent. Une capture d’écran montrant « aucun résultat » ne permet pas de distinguer un filtre métier, un cache, un droit d’accès et un défaut de lecture en base. L’équipe doit pouvoir reproduire le parcours exact avant d’attribuer la panne à une collation.

Comprendre pourquoi supprimer l’alerte ne reconstruit rien

Séparer la version enregistrée et les objets stockés

La référence ALTER COLLATION indique qu’un changement des règles de tri peut rendre des index incohérents. Elle demande de reconstruire les objets dépendants, puis d’actualiser la version. La commande REFRESH VERSION met à jour le catalogue et supprime l’avertissement ; elle ne vérifie pas que les objets affectés ont été correctement reconstruits.

Il faut donc conserver deux preuves différentes dans le dossier de changement. La première décrit l’environnement et ses versions. La seconde décrit les opérations réalisées sur les objets identifiés, puis les contrôles de résultats. Une ligne de journal propre après actualisation ne remplace pas le compte rendu de reconstruction. Cette séparation doit apparaître dans le runbook avant que l’alerte ne soit traitée.

Replacer le chantier dans le calendrier de maintenance

Au 24 octobre 2026, la politique officielle de support annonce la fin de support de PostgreSQL 14 au 12 novembre 2026. Ce repère justifie de revoir les trajectoires de migration des applications concernées. Il ne signifie pas que toute migration vers une version maintenue provoquera un changement de collation, ni que ce dossier impose une version cible unique.

Le choix de la version, du système et des bibliothèques forme un ensemble à recevoir. Une montée majeure et une simple mise à jour d’image ne suivent pas nécessairement la même procédure. Notez ce qui change réellement dans votre architecture : binaire PostgreSQL, fournisseur de collation, version de bibliothèque, extensions et réplicas. Le planning gagne en précision lorsque ces changements ne sont plus regroupés sous une case « mise à jour technique ».

Exemple : quatre lignes présentes, une recherche devenue fausse

Fixer deux ordres pédagogiques sans les attribuer à ICU

Notre jeu fictif contient quatre identités : 1 pour Aster, 2 pour Écume, 3 pour Orme et 4 pour Zèbre. L’ordre v1 place Aster, Orme, Zèbre, puis Écume. L’ordre v2 place Aster, Écume, Orme, puis Zèbre. Ces deux tables de rang sont écrites dans le programme ; elles ne prétendent représenter aucune locale française, aucun changement réel de glibc ou aucune version d’ICU.

L’index pédagogique est une liste construite selon v1. Une recherche dichotomique sous v2 suppose que cette liste respecte le nouvel ordre. Pour Écume, elle examine une zone qui exclut sa position réelle et conclut à une absence. Une recherche exhaustive dans les quatre lignes retrouve pourtant l’identité 2. Le contenu existe toujours ; c’est la relation entre l’organisation stockée et la comparaison utilisée qui est cassée.

Définir des témoins qui révèlent le défaut

Le nombre de lignes reste quatre à chaque étape. Une empreinte calculée sur les identités et leurs libellés, indépendamment de l’ordre, reste elle aussi identique. Enfin, changer le marqueur de version en v2 fait disparaître le décalage enregistré, mais laisse la recherche incorrecte. Ces trois critères sont donc insuffisants pour accepter notre scénario : comptage, contenu identique et versions égales.

Après reconstruction selon v2, les quatre recherches retrouvent les identités attendues. Le programme vérifie aussi un sous-ensemble sans Écume : son ordre reste compatible et peut donner un contrôle rassurant malgré un défaut ailleurs. Ce témoin explique pourquoi la sélection des cas métier compte autant que la présence d’un test dans la CI. Une recette composée uniquement des valeurs qui ne bougent pas manque précisément le risque étudié.

Relever la base, les collations et les versions réellement servies

Commencer par une observation en lecture seule

Le catalogue pg_database expose notamment le fournisseur de locale et la version enregistrée de la base. Les fonctions d’administration des collations permettent de demander la version courante. La requête suivante est un point de départ pour PostgreSQL 18 ; sa compatibilité doit être vérifiée avec la version effectivement exploitée.

SELECT datname,
       datlocprovider,
       datcollversion AS version_enregistree,
       pg_database_collation_actual_version(oid)
         AS version_actuelle
FROM pg_database
WHERE datname = current_database();

Cette lecture ne reconstruit aucun index et ne modifie aucune version. Conservez le résultat avec l’identité du serveur interrogé et l’image réellement en service. Une valeur absente demande une qualification selon le fournisseur ; elle ne devient pas automatiquement une preuve d’égalité. Si un proxy répartit les connexions, identifiez la cible obtenue plutôt que de supposer que toutes les lectures viennent du primaire.

Ne pas oublier les collations explicites

Une base peut utiliser plusieurs collations. Le contrôle du seul défaut de base ne décrit pas chaque expression ou colonne. Inventoriez également les collations nommées utilisées par le schéma et rapprochez leur version enregistrée de leur version courante. L’extrait suivant montre les observations brutes du catalogue courant ; il ne prétend pas lister à lui seul tous les objets applicatifs dépendants.

SELECT namespaces.nspname AS schema_name,
       collations.collname,
       collations.collprovider,
       collations.collversion AS version_enregistree,
       pg_collation_actual_version(collations.oid)
         AS version_actuelle
FROM pg_collation AS collations
JOIN pg_namespace AS namespaces
  ON namespaces.oid = collations.collnamespace
ORDER BY namespaces.nspname, collations.collname;

Les exemples SQL sont fournis pour préparer le diagnostic avec l’administrateur ; ils n’ont pas été exécutés sur votre base par le programme Python. Le livrable utile associe ensuite chaque collation pertinente à ses objets et usages. Une exportation brute de centaines de lignes de catalogue ne vaut pas encore une décision de maintenance.

Construire un périmètre de reconstruction vérifiable

Partir des dépendances, puis retrouver les usages

La documentation ALTER COLLATION fournit une requête de dépendances pour les collations dont les versions diffèrent. Utilisez-la comme point d’entrée, puis vérifiez le défaut de base et les dépendances de votre schéma. Le plan doit identifier les objets à traiter et les cas qui demandent une analyse supplémentaire. Une commande générale exécutée sans inventaire ne permet pas d’expliquer ce qui a réellement été couvert.

Rattachez les objets aux usages : recherche de tiers dans le CRM, liste de commandes, export envoyé à l’ERP, filtre d’un portail ou traitement d’un worker. La même table peut alimenter plusieurs chemins, dont certains passent par une API ou une réplique de lecture. Cette cartographie donne un ordre de priorité métier sans réduire le problème au seul écran qui a déclenché le ticket.

Conserver les objets exclus et leurs raisons

Le périmètre doit dire quels index sont reconstruits, quels autres objets dépendants sont examinés et pourquoi certains éléments sont exclus. Ne présentez pas une réindexation comme une réparation universelle de toute donnée dérivée. Une vue matérialisée, une règle de partitionnement ou une expression métier demande une qualification selon son usage ; la méthode retenue doit être décidée à partir du schéma réel.

Les entrées du chantier sont l’inventaire, les versions et les parcours à recevoir. Les sorties attendues sont un journal d’exécution et des résultats comparables. La responsabilité de valider le périmètre revient à l’équipe qui maîtrise la base et l’application ; le runbook conserve les dépendances non résolues et le seuil d’arrêt. Une liste vide issue d’un filtre incomplet ne constitue pas une autorisation de clôture.

Choisir une reconstruction compatible avec la disponibilité attendue

Arbitrer les verrous et le coût de l’opération

La référence REINDEX distingue la reconstruction classique et CONCURRENTLY. La première peut bloquer les écritures et des lectures utilisant l’index. La seconde réduit le blocage des écritures, mais demande davantage de travail, plusieurs phases et des attentes de transactions. Elle ne signifie ni absence de charge ni durée garantie.

La décision dépend de la fenêtre admissible, de la taille des objets, de la charge et de la capacité disponible. Une plateforme peu utilisée pendant une fenêtre planifiée n’a pas les mêmes contraintes qu’un portail recevant des écritures continues. Mesurez en répétition la durée, les attentes, les volumes temporaires et l’impact sur les requêtes ; ne copiez pas un délai observé sur quatre lignes dans un engagement de production.

Traiter les limites et les échecs comme des états du chantier

La même référence précise que REINDEX CONCURRENTLY ne s’exécute pas dans un bloc de transaction et comporte des restrictions, notamment pour les index de contraintes d’exclusion et les catalogues système. Un échec peut laisser un index invalide. La procédure de reprise doit qualifier l’objet exact et son état avant toute action ; supprimer des objets sur la seule base d’un nom ressemblant à un suffixe de travail serait imprudent.

L’instrumentation suit chaque objet, sa phase, ses attentes et sa preuve de fin. La vue de progression des constructions d’index expose les phases utiles, y compris pour REINDEX. Le monitoring et la journalisation doivent permettre au responsable de distinguer un travail encore actif, une attente de verrou et une erreur terminale, afin de ne pas lancer une seconde reconstruction à l’aveugle.

Vérifier les réplicas et préparer un retour cohérent

Ne pas valider toute la plateforme depuis un seul serveur

La documentation amcheck cite les différences de règles de collation entre primaire et serveur de secours parmi les causes d’incohérences. Certaines anomalies peuvent n’être visibles que sur le secours. Une preuve obtenue sur le primaire ne suffit donc pas à accepter un chemin de lecture qui utilise un autre environnement.

Dans l’exercice local, une copie reconstruite passe les contrôles tandis qu’une copie conservant l’ancien ordre échoue encore. Il s’agit de deux listes Python, pas d’une réplication PostgreSQL exécutée. La leçon de recette est d’attribuer chaque résultat à la cible testée. Pour l’installation réelle, l’administrateur choisit la procédure adaptée à la topologie et à l’alignement des bibliothèques ; le dossier n’ordonne pas de réindexer directement une réplique physique en lecture seule.

Définir ce que le rollback restaure réellement

Revenir à une ancienne image applicative ne remet pas automatiquement les bibliothèques et les structures de la base dans leur état antérieur. Le retour doit préciser la version du moteur, les données, les objets reconstruits et les écritures reçues depuis la bascule. Un plan de reprise qui dit seulement « remettre le conteneur précédent » laisse cette compatibilité sans réponse.

Préparez une restauration éprouvée et un point de décision avant ouverture. Le coût complet comprend la fenêtre de maintenance, la réception des résultats et le traitement des écritures intervenues après le changement. Une sauvegarde disponible est utile ; la preuve qu’elle peut restaurer un service cohérent avec ses dépendances l’est davantage. Le responsable métier doit savoir quelle activité serait à rejouer ou à rapprocher.

Recevoir les recherches, les contraintes et les parcours métier

Comparer les identités, pas seulement les nombres de lignes

Le fichier ordre_index.py contient les deux règles fictives, une recherche dichotomique et les 23 contrôles. Il détecte trois clôtures insuffisantes : quatre lignes présentes, empreinte du contenu inchangée et marqueur de version actualisé. Après reconstruction, il vérifie les quatre identités, l’ordre attendu et la conservation du contenu. Aucun serveur ni fichier de base n’est créé.

python3 ordre_index.py
# 23 contrôles réussis
# Versions égales seules : recette refusée
# Ordre reconstruit : quatre identités retrouvées

Pour votre application, construisez une population de référence avec identifiants stables et résultats attendus par requête. Couvrez les libellés représentatifs, les caractères utilisés, les recherches exactes et les tris qui décident d’une page ou d’un lot. Une comparaison de parcours avec et sans index doit être préparée par l’équipe base, avec lecture des plans et maîtrise du coût ; un réglage du planificateur ne doit pas devenir une correction permanente improvisée.

Associer les contrôles de structure et de métier

Le module amcheck peut vérifier des invariants des index B-tree ; ses fonctions n’ont pas toutes le même niveau de contrôle ni les mêmes verrous. Sa documentation précise qu’il peut établir la présence d’une corruption, mais pas en prouver l’absence. Choisissez les contrôles adaptés avec l’administrateur, puis conservez leur portée exacte. Un retour sans erreur ne doit pas être présenté comme une certification exhaustive de la base.

La QA doit également ouvrir les parcours backend et frontend : recherche d’un client, pagination, export et traitement différé. Une contrainte d’unicité ou une règle d’égalité mérite des cas propres à sa configuration ; notre exemple d’ordre ne démontre pas que deux chaînes deviennent égales. L’acceptation porte sur les usages réellement ouverts, avec les droits et la topologie qui seront servis après déploiement.

Erreurs fréquentes : confondre propreté du journal et résultat correct

• À faire : conserver le message initial, identifier le fournisseur et relier les objets aux parcours qui les utilisent.
• À différer : l’actualisation de version tant que la reconstruction et sa réception ne sont pas documentées.
• À refuser : une clôture fondée uniquement sur le redémarrage, le comptage ou l’absence d’avertissement.

Prendre un témoin stable pour une preuve générale

Paradoxalement, le succès d’un petit jeu de tests peut retarder le diagnostic s’il contient seulement des valeurs dont l’ordre ne change pas. Le programme montre ce cas avec le sous-ensemble sans Écume. Il ne faut pas multiplier artificiellement les exemples ; il faut choisir ceux qui distinguent la propriété contrôlée. Un test doit pouvoir échouer lorsque l’ancien ordre est réellement utilisé avec la nouvelle comparaison.

Gardez aussi une séparation entre performance et correction. Une requête rapide qui oublie un dossier n’est pas acceptable. Une requête exhaustive qui retrouve tout peut, elle, être trop coûteuse pour le service courant. La recette doit donc relever les résultats et le coût sur une population représentative, sans utiliser l’un comme substitut de l’autre.

Reporter le problème sur le cache ou sur l’utilisateur

Vider le cache peut modifier le chemin emprunté et donner l’impression d’une réparation. Demander au gestionnaire de ressaisir le nom peut également contourner un cas. Ces observations sont utiles au diagnostic, mais ne justifient pas de fermer l’incident sans expliquer la cause. Le dossier doit conserver le témoin initial et montrer pourquoi il produit désormais le résultat attendu.

La charge support augmente lorsque l’équipe transforme chaque recherche manquante en ticket indépendant. Regroupez les incidents par version servie, cible de lecture et objet concerné. Cela permet de borner le périmètre sans déclarer tous les utilisateurs affectés. La correction peut ensuite être reçue sur les mêmes témoins, puis surveillée dans le run quotidien.

Plan d’action : préparer, reconstruire et recevoir avant la clôture

Constituer le dossier avant la fenêtre technique

Commencez par une application et une base identifiées, avec leurs cibles de lecture. Relevez les versions exécutées, les fournisseurs de collation et les changements prévus dans l’image ou le système. Associez chaque observation à sa date et à son serveur. Si le décalage est déjà apparu, conservez le message initial avant toute actualisation. Cette trace permettra de comprendre le problème même lorsque la maintenance aura modifié les métadonnées.

Établissez l’inventaire des objets avec l’équipe base et reliez-le aux usages critiques. Choisissez les témoins métier, les identifiants attendus et les critères de refus avant d’exécuter la procédure. Préparez une restauration testée et une décision explicite sur les écritures pendant la fenêtre. Le livrable doit dire qui autorise la poursuite, qui reçoit les résultats et qui prend en charge un objet dont l’état reste inconnu.

Répéter le scénario sur un périmètre représentatif

Exécutez la procédure de reconstruction retenue dans un environnement de recette pertinent, avec la version cible et un volume justifié. Mesurez la durée, les attentes de transactions, la charge et l’espace nécessaire. Conservez les objets réellement traités et les éventuels échecs ; une commande terminée ne dispense pas de comparer le périmètre obtenu à l’inventaire attendu. Toute exclusion doit rester visible dans la décision de réception.

Rejouez ensuite les recherches et les traitements définis avant l’essai. Vérifiez les identités, l’ordre et les contraintes pertinentes, puis les écrans, les exports et les cibles de lecture. Les résultats doivent être rattachés à l’exécution qui a reconstruit les objets. Faites relire le dossier par une personne capable de retrouver un témoin sans explication orale du développeur ; cette autonomie révèle souvent les références ou les étapes manquantes.

• Preuve système : versions servies et cibles interrogées.
• Preuve base : objets traités, résultats et exceptions.
• Preuve métier : identités retrouvées et usages reçus.

Actualiser puis surveiller le périmètre ouvert

Lorsque la reconstruction et les contrôles sont reçus, l’administrateur actualise la version enregistrée avec la commande adaptée à la collation nommée ou au défaut de base. Ce geste clôt le décalage de métadonnées ; il ne remplace pas les preuves précédentes. Enregistrez les versions finales, le périmètre accepté et les réserves éventuelles. Une restriction d’usage doit rester explicite tant qu’une cible n’a pas été vérifiée.

Surveillez les recherches manquantes, les écarts entre cibles et les incidents de performance après ouverture. Définissez un seuil de revue selon la criticité : dans notre scénario, toute identité attendue absente refuse la réception. Le suivi doit conserver un responsable et une prochaine action. Réutilisez enfin ce dossier lors du prochain changement d’image, afin que les bibliothèques de comparaison restent une dépendance connue de votre application.

Relier les collations à la migration et à la reprise du logiciel

Le dossier sur les risques d’une migration de base de données couvre les identités, relations et historiques à préserver. La recette métier d’une migration aide à construire les témoins et les critères de signature. Le changement de règles de tri ajoute ici un risque ciblé sur les structures et les lectures, même lorsque les données copiées sont identiques.

Pour préparer l’exécution, la répétition générale du runbook de migration relie les étapes et les décisions de bascule. Le dossier restaurer le logiciel, ses données et ses documents complète le retour au service. Ces préparations doivent intégrer l’environnement de la base, pas uniquement la dernière version du code applicatif.

Reprendre une construction qui laisse un index invalide

Une reconstruction peut elle-même rencontrer un échec. Le diagnostic d’un index présent mais inutilisable après une création concurrente distingue le nom de l’objet, sa définition et les indicateurs du catalogue. Il explique pourquoi une relance fondée sur IF NOT EXISTS peut constater la présence sans réparer l’état attendu.

Cette vérification intervient après l’identification des objets à reconstruire : elle ne remplace pas l’analyse du changement de collation. Son exercice à huit observations aide à préparer une postcondition de migration, puis une réception du parcours. Il faut encore vérifier l’activité de construction et les dépendances avant de choisir une reprise, afin de ne pas supprimer un objet simplement parce qu’il apparaît invalide à un instant donné.

Conclusion : reconstruire la preuve avant de fermer l’alerte

Une alerte de collation signale un écart à qualifier entre une version enregistrée et l’environnement utilisé. Sa disparition ne garantit pas la correction des objets qui dépendaient des anciennes règles. La clôture doit donc réunir un périmètre, une reconstruction appropriée et des résultats vérifiés sur les cibles réellement servies.

Le scénario à quatre libellés conserve toutes ses données et peut pourtant manquer Écume. Ses 23 contrôles montrent pourquoi comptage, empreinte et version alignée ne suffisent pas. Cette démonstration locale explique un invariant de recherche ; seule la recette de votre installation peut établir ce qui a été reconstruit et quels usages sont reçus.

L’audit technique d’une application web permet de relier ces dépendances aux parcours métier, aux procédures de maintenance et aux conditions de reprise. Les décisions deviennent plus faciles à défendre lorsque les preuves de base et les preuves d’usage sont conservées ensemble.

Dawap accompagne le développement web sur mesure et l’évolution des applications métier en coordonnant architecture, intégrations et exploitation. Vos équipes disposent ainsi de critères concrets pour faire évoluer le logiciel et son environnement sans confondre un service redémarré avec un service correctement reçu.