REMARQUE : Je ne suis pas sûr de la raison, mais la mise à niveau vers PostgreSQL 18 désactive les contrôles de cohérence des données natifs. Les contrôles de cohérence des données PostgreSQL sont une fonctionnalité par défaut et il semble très inhabituel de les désactiver.
PR pour ne pas désactiver les vérifications de données (activées par défaut) : Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
Et c’est mieux que d’avoir 20 Go libres pour la seule heure où tu en as besoin dans l’année lol
Peut-être que cela devrait être la méthode recommandée afin d’économiser les arbres et l’eau. 
Juste pour confirmer, je n’utilise pas PostgreSQL fourni par Discourse et Discourse lui-même ne nécessite pas encore PG18, n’est-ce pas ? Donc je ne suis pas (encore) tenu de passer à PG18.
Bonne remarque. Mais l’autre point est que les versions LTS sortent tous les deux ans, donc ce n’est pas une mauvaise idée de le faire en même temps.
Vous avez encore tout votre temps. Ils ont poussé pour… euh, une sortie assez rapidement après la mise à jour à cause d’une fonctionnalité requise, mais vous pouvez probablement attendre jusqu’à un an. Je surveille le dépôt discourse_docker. À un moment donné, ils commenceront à parler de la suppression du support pour PG15 ; ce n’est pas particulièrement bruyant et c’est un moyen simple de rester au courant des mises à jour des composants internes.
2 « J'aime »
Ça a fonctionné sans problème sur mon installation Pi 5, deux reconstructions et c’était terminé.
7 « J'aime »
Avez-vous des benchmarks, au fait ?
Cela pourrait encourager d’autres à nous suivre dans nos pas intrépides plus rapidement.
Mon IA de recherche web gratuite me dit :
Pour une application Rails typique, passer de PostgreSQL 15 à 18 peut offrir ~10–25 % de performances de requête plus rapides sans modification du code, et jusqu’à 40 % pour certains modèles de requêtes si vous exploitez les nouvelles fonctionnalités d’indexation et de planification.
Si c’est vrai, c’est une mise à niveau assez impressionnante ! 
7 « J'aime »
Juste pour confirmer que tout s’est déroulé sans accroc sur notre instance auto-hébergée. Merci pour cette mise à jour et gardez-nous informés.
5 « J'aime »
C’est vrai, mais nous visons un mécanisme de mise à jour simple et transparent. Il y a des avantages des deux côtés.
Je dirais que vous devez faire ce qui vous semble le plus confortable et ne pas avoir peur de personnaliser les modèles dans discourse_docker selon vos besoins. Évidemment, la clé est de tester en premier et d’avoir un plan de retour en arrière.
Sur notre plateforme hébergée, nous avons l’intention de faire plus de tests et de benchmarks avant de les activer, et donc je les ai désactivés dans discourse_docker également pour aligner la configuration. Ce n’est pas strictement nécessaire de les désactiver (nous n’utilisons que la partie conteneur web de discourse_docker en interne) et je ne serais pas contre les activer.
Un piège potentiel est que pg_upgrade ne fonctionnera pas si les anciens et nouveaux répertoires de données ont des paramètres de sommes de contrôle différents. Le processus consisterait à arrêter le serveur PG15, exécuter pg_upgrade pour le convertir en PG18 sans sommes de contrôle, exécuter pg_checksums pour activer les sommes de contrôle, puis démarrer PG18. Ce n’est pas un problème lors d’une sauvegarde et restauration (comme avec cette mise à niveau), mais c’est quelque chose à surveiller.
Notez que les sommes de contrôle de données sont disponibles depuis Postgres 9.3 mais ont été désactivées par défaut jusqu’à présent. Postgres 19 inclura également la possibilité de les activer/désactiver en ligne.
Pas à ce stade, non. La plupart des fonctionnalités de Discourse utilisent l’adaptateur PostgreSQL de Rails pour communiquer avec la base de données, mais la sauvegarde/restoration utilise pg_dump et psql dans le conteneur web. Pour l’instant, nous installons les clients PG15 et PG18 pour permettre la sauvegarde/restoration avec ces deux versions, mais à un moment donné dans le futur, nous supprimerons PG15.
Le facteur déterminant était le passage au nouveau fournisseur de locales intégré. Nous travaillons vers une mise à niveau du système d’exploitation sur notre plateforme hébergée et voulons briser le couplage avec glibc.
3 « J'aime »
Je gère mon instance PostgreSQL de manière indépendante du conteneur. Quel est le hash Git recommandé vers lequel je devrais basculer pour passer à la version 18 ?
1 « J'aime »
e7f1201 a ajouté le client PG18 à l’image web pour la compatibilité des sauvegardes. Si vous n’utilisez aucun des composants du serveur Postgres de discourse_docker, c’est la révision la plus ancienne que vous devriez utiliser pour PG18.
1 « J'aime »
Je parlais d’une ou deux mises à niveau plus tôt.
D’accord. Mon point était simplement qu’il n’est pas moins soutenu de pouvoir restaurer une ancienne sauvegarde PostgreSQL sur une version plus récente. Le mécanisme de mise à niveau in situ fonctionne remarquablement bien pour la grande majorité des utilisateurs, mais lorsque quelque chose se passe mal, il est difficile de savoir quoi faire (principalement parce que cela arrive si rarement).
2 « J'aime »
Si cela peut aider quelqu’un, pour ces moments où la console SSH reste figée et où la sueur froide de la panique commence à poindre…
J’ai exécuté ceci dans un autre terminal pour surveiller la progression :
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Ce qui vous met à jour toutes les 10 s et vous garde sain d’esprit
Ma migration de 35 Go a pris environ 10 minutes.
8 « J'aime »
La mise à jour s’est déroulée sans problème avec l’installation standard. Bien sûr, j’ai fait une sauvegarde et l’ai téléchargée au cas où quelque chose tournerait mal 
3 « J'aime »
Pas mal. J’ajouterais un free -h à ça — la pénurie de mémoire est un problème assez courant.
Le seul inconvénient avec watch ou même top, c’est que l’affichage se rafraîchit en permanence, donc tu risques de passer à côté de quelque chose. Si tu tombes en panne de quelque chose et que la mise à jour échoue, quelques secondes plus tard, tu as perdu la trace. Du coup, j’ai tendance à utiliser quelque chose comme une boucle while — peut-être comme ceci :
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 « J'aime »
Je peux annoncer un succès . . . pour la moitié de ma configuration multisite. Le site par défaut a migré comme prévu, mais le site secondaire ressemblait à une installation neuve. Heureusement, il n’est pas difficile de restaurer une sauvegarde. J’ai un autre serveur que j’utilise pour mes clients, et je pense créer une nouvelle Droplet et restaurer les sites à partir des sauvegardes pour effectuer cette mise à jour. C’est l’un des risques de l’utilisation d’une installation non standard, je suppose.
1 « J'aime »
Votre conteneur de données était-il un conteneur de données standard ? Je me demandais s’il déplacerait une seule base de données ou toutes celles du cluster. Il semble que vous ayez répondu à ma question !
Ce que je fais, c’est déplacer manuellement chaque base de données de l’ancien cluster vers le nouveau, puis modifier manuellement discourse.conf pour pointer vers la nouvelle base de données, et enfin effectuer une reconstruction pour orienter l’ensemble du conteneur multisite vers le nouveau cluster (sur une machine ou un port différent).
1 « J'aime »
Oui. Bien sûr, je ne peux pas affirmer n’avoir rien foiré dans ma configuration. 
J’avais prévu de rsync mes données PostgreSQL pour y exécuter une mise à niveau de QN afin de vérifier avec certitude si le processus déplaçait uniquement la base de données Discourse ou l’ensemble du cluster, mais il semble que vous ayez répondu à ma question et que cela sera clair si j’examine le code.
2 « J'aime »
J’ai deux questions ici :
- Nous avons monté un bloc de stockage supplémentaire sur le serveur de test. Mais la mise à jour de PostgreSQL échoue car la vérification de l’espace ne concerne que le disque principal. Y a-t-il un moyen de contourner cette vérification d’espace ?
- Pour notre site de production, nous utilisons Google Cloud SQL. Y a-t-il des points à connaître avant la mise à jour via Google Cloud ?