Les sauvegardes ne fonctionnent plus pour une base de données postgres 16 en raison de ce commit qui installe postgresql-client-${PG_MAJOR} plutôt que postgresql-client.
Est-ce que cela résout un problème ? Le client psql fourni par l’OS ne fonctionnait-il pas très bien avec toutes les versions de postgres ?
J’ai été surpris que ce client utilise PG16 sur une base de données Digital Ocean, mais je pensais savoir que certains hébergements CDCK utilisaient maintenant PG15.
Existe-t-il une meilleure façon d’obtenir une sauvegarde fonctionnelle que quelque chose comme ceci :
J’ai découvert ce bug lorsqu’une sauvegarde Discourse a été effectuée à l’aide de pg_dump version 17.2, qui ne peut pas être restaurée sur des clusters PostgreSQL < 17.2.
Comme pg_dump est utilisé pour transférer des données vers des versions plus récentes de PostgreSQL, la sortie de pg_dump peut être chargée dans des serveurs PostgreSQL plus récents que la version de pg_dump. pg_dump peut également sauvegarder à partir de serveurs PostgreSQL plus anciens que sa propre version. (Actuellement, les serveurs jusqu’à la version 9.2 sont pris en charge.) Cependant, pg_dump ne peut pas sauvegarder à partir de serveurs PostgreSQL plus récents que sa propre version majeure ; il refusera même d’essayer, plutôt que de risquer de créer une sauvegarde invalide. De plus, il n’est pas garanti que la sortie de pg_dump puisse être chargée dans un serveur d’une version majeure plus ancienne, même si la sauvegarde a été effectuée à partir d’un serveur de cette version. Le chargement d’un fichier de sauvegarde dans un serveur plus ancien peut nécessiter une édition manuelle du fichier de sauvegarde pour supprimer la syntaxe non comprise par le serveur plus ancien.
Oups. Et je pensais avoir lu la PR. Étant un locuteur natif anglais avec un doctorat, on pourrait penser que je ferais mieux.
Non. Je ne peux pas, car c’est ce qui construit l’image de base.
Donc, il semble que ma correction soit aussi bonne que possible, bien que si j’étais plus malin, j’expurgerais les éléments apt que j’extrais avec apt-get update.
J’imagine que d’autres auront ce problème, car il est souvent difficile de convaincre divers humains et systèmes que vous voulez PG13 plutôt que quelque chose de plus récent. Et il semble que cela fait assez longtemps que quelqu’un qui sait a dit que Discourse fonctionnait avec PG15.
(Je vois que mon installation ordinaire utilise la version 13, donc je suppose que cette situation est un peu spéciale, bien que peut-être pas terriblement rare.)
Salut à tous, j’ai rencontré ce problème aujourd’hui. Le symptôme était que nous recevions des alertes depuis environ 6 jours indiquant que les sauvegardes échouaient, et les lignes de log clés semblaient être :
[2025-06-14 03:30:20] pg_dump: error: aborting because of server version mismatch
[2025-06-14 03:30:20] pg_dump: detail: server version: 16.9; pg_dump version: 15.12 (Debian 15.12-1.pgdg120+1)
J’utilise Discourse sur Ubuntu installé via le guide d’installation recommandé sur un droplet Digital Ocean. Mais j’utilise la base de données PostgreSQL gérée de Digital Ocean plutôt qu’un conteneur PostgreSQL. En regardant ma base de données, elle fonctionne avec pg 16. Je ne pense pas qu’ils l’aient mise à jour récemment (et je ne m’attendrais pas à ce qu’une mise à niveau de version majeure soit automatique de toute façon), mais j’ai contacté leur support pour vérifier.
Quoi qu’il en soit, mes recherches m’ont mené à cette page. Je n’étais pas sûr où placer le YAML que @pfaffman a posté, alors j’ai exécuté les commandes manuellement, et j’ai pensé partager pour quiconque tomberait sur ce problème :
cd /var/discourse
launcher enter app
apt list --installed | grep postgres # pour confirmer que la version actuellement installée est 15
Cela semble avoir temporairement résolu le problème, mais comme l’a souligné @pfaffman, je m’attends à ce que la prochaine fois que je mettrai à niveau Discourse, il revienne à postgresql-client-15, et les sauvegardes cesseront de fonctionner à nouveau, nécessitant l’intervention manuelle ci-dessus.
Existe-t-il une solution à ce problème autre que de devoir répéter ces étapes à chaque mise à niveau de Discourse ?
Merci, mais je ne suis pas sûr de bien comprendre. J’ai l’impression que le YAML que vous avez mentionné dans le message original ci-dessus était simplement un moyen de réduire les commandes du petit nombre que j’ai posté ci-dessus à une seule, mais que vous deviez toujours l’exécuter manuellement à chaque fois que vous mettez à niveau Discourse. Ai-je mal interprété ?