Is there somewhere a note, which postgresql db versions are supported?
Would be great to have something for each released discourse version - especially if a postgresql version is no longer supported.
Postgres is bundled in with the Docker container for Discourse, so this is generally hands-off. The Discourse team upgrades the Postgres version as new releases come out and they are properly tested. The most recent upgrade was to version 13. You can see the details of that upgrade here:
3 « J'aime »
Well, not everyone is using the bundled postgres db.
The current install doc lists Postgres 10+ as the required version:
https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
That said, the only officially supported setups are using Docker containers.
2 « J'aime »
Yes, the versions of postgres which are “supported” (from a docker build perspective, not all “strongly supported”) are listed in the templates directory of discourse_docker
Having said that, it is highly recommended to move to the latest version of postgres, currently version 13, as soon as you can.
However, if you are running Discourse on a host where you cannot run the latest version because of some local constraint in your organization; the discourse_docker templates directory is a good place to research.
4 « J'aime »
Vérification trois ans plus tard : le modèle Docker indique toujours PG_MAJOR=13, mais il existe de nouvelles versions de PostgreSQL : 14 à partir de 2021, 15 à partir de 2022 et 16 à partir de 2023.
La recommandation est donc toujours d’utiliser la version 13 (qui arrivera en fin de vie en 2025) plutôt que la dernière version de PostgreSQL 16 (qui arrivera en fin de vie en 2028) ?
Oui, exactement.
Nous avons certains sites qui fonctionnent déjà avec la version 15 et devrions passer à la mise à jour de la version 13 l’année prochaine.
1 « J'aime »
Question : quel est le statut actuel ici ? J’exécute une base de données pg externe et j’aimerais mettre à niveau le serveur de base de données depuis la version 13. PostgreSQL 16 est sorti le 2023-09-14. Peut-il être utilisé avec Discourse ? Des étapes de migration seront-elles nécessaires pour la base de données elle-même ? (en dehors des étapes de migration globales côté serveur)
PostgreSQL 13 est toujours la version officiellement prise en charge, la version 13.15 ayant été publiée le mois dernier et toujours prise en charge.
Nous avons un bon nombre de sites exécutant la version 15, et c’est une version fonctionnelle connue pour laquelle nous prévoyons d’expédier une mise à jour pour les utilisateurs auto-hébergés à terme.
La version 16 n’est pas largement testée en dehors des machines de développement, mais si vous vous sentez aventureux et souhaitez l’essayer pour voir si quelque chose se casse, faites-nous savoir comment cela se passe !
1 « J'aime »
Discourse fait-il quelque chose d’inhabituel avec Postgres qui impliquerait que les mises à niveau vers de nouvelles versions de Postgres pourraient ne pas fonctionner avec un simple dump et restore ?
Remontée de ce fil pour savoir s’il y a une raison de tenter de passer à PostgreSQL 15 au lieu de 16 ou 17 ?
Et quand devrions-nous nous attendre à mettre à niveau PostgreSQL
Salut tout le monde, je viens de passer à AWS RDS PostGre 16.4 et cela semble fonctionner.
Je suis sur la version de Discourse 3.4.0.beta3-dev
Je n’ai pas encore appuyé sur tous les boutons 
, mais le tableau de bord lui-même semble fonctionner, mais…
Je ne peux pas créer de sauvegardes, à cause de
[2024-12-13 08:36:07] Vérification de l'existence de '/var/www/discourse/tmp/backups/default/2024-12-13-083607'...
[2024-12-13 08:36:07] Vérification de l'existence de '/var/www/discourse/public/backups/default'...
[2024-12-13 08:36:07] Mise à jour des métadonnées...
[2024-12-13 08:36:07] Sauvegarde du schéma public de la base de données...
[2024-12-13 08:36:08] pg_dump: erreur : version du serveur : 16.4 ; version de pg_dump : 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: erreur : abandon en raison d'une incompatibilité de version du serveur
[2024-12-13 08:36:08] EXCEPTION : pg_dump a échoué
La chose étrange est que j’ai pu importer les données avec les mécanismes internes :
Ce que j’ai fait :
- Configuration de la base de données (utilisateur, base de données, octrois)
- Configuration dans app.yml
- Création d’une sauvegarde depuis Discourse
- Reconstruire l’application (la migration de la base de données a réussi → la base de données est vide alors)
- Restauration de la sauvegarde depuis le conteneur (launcher enter app, discourse enable_restore, discourse restore …)
- Fin (tout a réussi, et tout semblait fonctionner, jusqu’à ce que j’essaie de créer une nouvelle sauvegarde )
Y a-t-il une chance de résoudre ce problème d’une manière ou d’une autre ?
Salutations,
JP
1 « J'aime »
Ok les gars, ça devient intéressant maintenant.
Je n’ai pas travaillé pendant quelques jours et je n’ai pas vérifié notre nouveau tableau de bord d’entreprise.
Quand j’ai vérifié aujourd’hui, la sauvegarde planifiée a fonctionné, puis j’ai essayé de faire la sauvegarde manuelle à nouveau, et ça a échoué 
planifiée :
Dumping the public schema of the database...
[2024-12-04 06:02:16] pg_dump: last built-in OID is 16383
[2024-12-04 06:02:16] pg_dump: reading extensions
[2024-12-04 06:02:16] pg_dump: identifying extension members
[2024-12-04 06:02:16] pg_dump: reading schemas
[2024-12-04 06:02:16] pg_dump: reading user-defined tables
[2024-12-04 06:02:16] pg_dump: reading user-defined functions
[2024-12-04 06:02:16] pg_dump: reading user-defined types
......
pg_dump: dumping contents of table "public.themes"
[2024-12-04 06:02:19] pg_dump: processing data for table "public.top_topics"
[2024-12-04 06:02:19] pg_dump: dumping contents of table "public.top_topics"
[2024-12-04 06:02:19] Finalizing backup...
[2024-12-04 06:02:19] Creating archive: scp-talk-2024-12-04-060216-v20241127034553.tar.gz
[2024-12-04 06:02:19] Making sure archive does not already exist...
[2024-12-04 06:02:19] Creating empty archive...
[2024-12-04 06:02:19] Archiving data dump...
[2024-12-04 06:02:19] Archiving uploads...
[2024-12-04 06:02:19] Removing tmp '/var/www/discourse/tmp/backups/default/2024-12-04-060216' directory...
[2024-12-04 06:02:19] Gzipping archive, this may take a while...
[2024-12-04 06:02:19] Executing the after_create_hook for the backup...
[2024-12-04 06:02:19] Deleting old backups...
[2024-12-04 06:02:19] Cleaning stuff up...
[2024-12-04 06:02:19] Removing '.tar' leftovers...
[2024-12-04 06:02:19] Marking backup as finished...
[2024-12-04 06:02:19] Refreshing disk stats...
[2024-12-04 06:02:19] Notifying '<me>' of the end of the backup...
manuelle :
[2024-12-16 10:03:54] '<me>' has started the backup!
[2024-12-16 10:03:54] Marking backup as running...
[2024-12-16 10:03:54] Making sure '/var/www/discourse/tmp/backups/default/2024-12-16-100354' exists...
[2024-12-16 10:03:54] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-16 10:03:54] Updating metadata...
[2024-12-16 10:03:54] Dumping the public schema of the database...
[2024-12-16 10:03:54] pg_dump: error: server version: 16.4; pg_dump version: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-16 10:03:54] pg_dump: error: aborting because of server version mismatch
[2024-12-16 10:03:54] EXCEPTION: pg_dump failed
hmmmmm, des idées ?
Très étrange 
Je confirme que la mise à niveau vers la version 3.4.0.beta3 avec une base de données externe entraîne l’échec de la sauvegarde.
J’ai deux instances 3.4.0.beta3 (tag) : 1) avec Postgres-in-Docker (par défaut) ; 2) avec Postgres externe (auto-hébergé localement).
La première est capable de sauvegarder, à la fois par planification et manuellement :
[2024-12-23 11:11:43] Marquage de la sauvegarde comme en cours...
[2024-12-23 11:11:44] Vérification de l'existence de '/var/www/discourse/tmp/backups/default/2024-12-23-111143'...
[2024-12-23 11:11:44] Vérification de l'existence de '/var/www/discourse/public/backups/default'...
[2024-12-23 11:11:44] Mise à jour des métadonnées...
[2024-12-23 11:11:44] Vidage du schéma public de la base de données...
[2024-12-23 11:11:44] pg_dump: le dernier OID intégré est 16383
[2024-12-23 11:11:44] pg_dump: lecture des extensions
[2024-12-23 11:11:44] pg_dump: identification des membres de l'extension
[2024-12-23 11:11:44] pg_dump: lecture des schémas
...
La seconde échoue :
[2024-12-21 03:35:21] Marquage de la sauvegarde comme en cours...
[2024-12-21 03:35:21] Vérification de l'existence de '/var/www/discourse/tmp/backups/default/2024-12-21-033521'...
[2024-12-21 03:35:21] Vérification de l'existence de '/var/www/discourse/public/backups/default'...
[2024-12-21 03:35:21] Mise à jour des métadonnées...
[2024-12-21 03:35:21] Vidage du schéma public de la base de données...
[2024-12-21 03:35:22] pg_dump: erreur : version du serveur : 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1) ; version de pg_dump : 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: erreur : abandon en raison d'une incompatibilité de version du serveur
[2024-12-21 03:35:22] EXCEPTION : pg_dump a échoué
...
2 « J'aime »
J’ai mis à niveau hier et je confirme que les sauvegardes planifiées échouent en raison d’une incompatibilité de version.
Vous pouvez corriger cela en entrant dans Docker et en installant un client postgresql plus récent.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 « J'aime »
Salut tout le monde,
J’ai maintenant basculé vers des bases de données PostGre cryptées dans RDS, et j’ai fait la même chose hier (comme je l’ai décrit dans les étapes précédentes (faire une sauvegarde, modifier app.yml, reconstruire, …) et cela fonctionnait hier.
Aujourd’hui, j’ai essayé cela avec PROD et maintenant j’obtiens cette erreur 
Création des fonctions manquantes dans le schéma discourse_functions…
Restauration du fichier de vidage… (cela peut prendre un certain temps)
SET
SET
SET
ERREUR : paramètre de configuration « transaction_timeout » non reconnu
EXCEPTION : psql a échoué : ERREUR : paramètre de configuration « transaction_timeout » non reconnu
J’ai essayé cela directement avec DBeaver dans la base de données, et là j’obtiens la même erreur (même pour cette base de données, qui fonctionnait à merveille hier).
Les sauvegardes étaient à jour dans les deux cas.
Avez-vous changé quelque chose pendant la nuit ? 
Merci et salutations,
WS
Salut,
J’ai vérifié le dump effectué dans le fichier de sauvegarde :
Il inclut ceci en haut
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET transaction_timeout = 0;
SET client_encoding = ‘UTF8’;
SET standard_conforming_strings = on;
Le paramètre transaction_timeout est étrange ici 
car
transaction_timeout a été ajouté dans PostgreSQL 17.
comme indiqué ici :
https://pgpedia.info/t/transaction_timeout.html
Besoin d’aide 
Merci !
Cordialement,
Wurzelseppi
Existe-t-il un moyen de rendre cette mise à jour de postgresql-client une partie automatisée d’une reconstruction en modifiant le YAML du conteneur ?