Nous essayons de fournir des valeurs par défaut sensées dans les images discourse_docker, mais il est impossible de prendre en compte chaque cas d’utilisation possible. N’hésitez pas à personnaliser vos images pour conserver des versions antérieures si vous le préférez.
Dans une certaine mesure, les versions des dépendances reflètent nos exigences d’hébergement — nous utilisons l’image de base en interne. Cela signifie qu’elle ne doit pas devenir trop obsolète, mais cela implique aussi qu’il n’y a qu’un nombre limité de permutations que nous pouvons maintenir.
C’est une méthode tout à fait valable si elle vous inspire plus de confiance.
Si l’avertissement est généré lors de la préparation de l’exportation de l’ancienne base de données, il n’y a aucune raison de s’inquiéter. Nous exécutons le serveur uniquement contre l’ancien répertoire de données dans le but d’exécuter pg_dump. Lorsque l’exportation est restaurée sur le nouveau serveur, les index sont recréés.
La raison pour laquelle vous voyez cela est que nous avons publié ces derniers jours une nouvelle version de l’image de base qui passe de Debian Bookworm à Trixie, modifiant ainsi la version de glibc. Les locales basées sur le fournisseur libc (que vous utilisiez probablement) ne sont pas stables lors des mises à niveau de glibc, donc lorsque le script de mise à niveau démarre un serveur Postgres pour exporter vos anciennes données, il affiche des avertissements d’incompatibilité de classement.
Cette incompatibilité de classement est la raison principale pour laquelle nous effectuons une exportation et une restauration au lieu d’exécuter pg_upgrade. Une fois que votre base de données utilise C.UTF-8 avec le fournisseur builtin, les mises à niveau de glibc n’affecteront plus les classements.