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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
Prüfung nach drei Jahren: Die Docker-Vorlage sagt immer noch PG_MAJOR=13, aber es gibt neue Versionen von PostgreSQL: 14 aus 2021, 15 aus 2022 und 16 aus 2023.
Die Empfehlung lautet also immer noch, Version 13 (EOL 2025) anstelle der neuesten PostgreSQL 16 (EOL 2028) zu verwenden?
Ja, genau.
Wir haben einige Websites, auf denen bereits Version 15 läuft, und sollten im nächsten Jahr von Version 13 aktualisieren.
1 „Gefällt mir“
Frage: Wie ist hier der aktuelle Status? Ich betreibe eine externe PostgreSQL-Datenbank und möchte den Datenbankserver von Version 13 aufrüsten. PostgreSQL 16 wurde am 14.09.2023 veröffentlicht. Kann es mit Discourse verwendet werden? Sind irgendwelche Migrationsschritte für die Datenbank selbst erforderlich? (abgesehen von den globalen Migrationsschritten auf der Serverseite)
PostgreSQL 13 ist immer noch die offiziell unterstützte Version. Version 13.15 wurde letzten Monat veröffentlicht und wird immer noch unterstützt.
Wir haben eine gute Anzahl von Websites, auf denen Version 15 läuft. Dies ist eine bekannte funktionierende Version, für die wir irgendwann ein Update für Self-Hosted-Benutzer planen.
Version 16 ist außerhalb von Entwicklermaschinen nicht weit verbreitet getestet. Wenn Sie jedoch abenteuerlustig sind und es ausprobieren möchten, um zu sehen, ob etwas kaputt geht, lassen Sie uns wissen, wie es läuft!
1 „Gefällt mir“
Macht Discourse etwas Ungewöhnliches mit Postgres, was darauf hindeuten würde, dass Upgrades auf neue Postgres-Versionen möglicherweise nicht mit einem einfachen Dump und Restore funktionieren?
Diesen Thread hochschieben, um zu sehen, ob es einen Grund gibt, auf PostgreSQL 15 statt auf 16 oder 17 zu upgraden?
Und wann sollten wir mit dem Upgrade von PostgreSQL rechnen?
Hallo Leute, ich bin gerade auf AWS RDS PostGre 16.4 umgestiegen und es scheint zu funktionieren.
Ich bin auf Discourse Version 3.4.0.beta3-dev
Ich habe noch nicht auf alle Schaltflächen geklickt 
, aber das Board selbst scheint zu funktionieren, aber…
Ich kann keine Backups erstellen, wegen
[2024-12-13 08:36:07] Sicherstellen, dass '/var/www/discourse/tmp/backups/default/2024-12-13-083607' existiert...
[2024-12-13 08:36:07] Sicherstellen, dass '/var/www/discourse/public/backups/default' existiert...
[2024-12-13 08:36:07] Metadaten aktualisieren...
[2024-12-13 08:36:07] Das öffentliche Schema der Datenbank wird geleert...
[2024-12-13 08:36:08] pg_dump: Fehler: Serverversion: 16.4; pg_dump-Version: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: Fehler: Abbruch wegen Versionskonflikt des Servers
[2024-12-13 08:36:08] AUSNAHME: pg_dump fehlgeschlagen
Das Seltsame ist, dass ich die Daten tatsächlich mit internen Mechanismen importieren konnte:
Was ich getan habe:
- Datenbank eingerichtet (Benutzer, Datenbank, Berechtigungen)
- Konfiguration in app.yml
- Backup aus Discourse heraus erstellt
- App neu erstellt (Datenbankmigration erfolgreich → Datenbank ist dann leer)
- Backup aus dem Container wiederhergestellt (launcher enter app, discourse enable_restore, discourse restore …)
- Fertig (alles erfolgreich, und alles schien zu funktionieren, bis ich versuchte, ein neues Backup zu erstellen )
Gibt es eine Möglichkeit, das irgendwie anzugehen?
Grüße,
JP
1 „Gefällt mir“
Okay Leute, jetzt wird es interessant.
Ich habe ein paar Tage nicht gearbeitet und unser neues Firmen-Board nicht überprüft.
Als ich es heute überprüft habe, hat das geplante Backup funktioniert, dann habe ich versucht, das manuelle Backup erneut durchzuführen, und das ist fehlgeschlagen 
geplant:
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...
manuell:
[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
hmmmm, irgendwelche Ideen?
Sehr seltsam 
Ich bestätige, dass das Upgrade auf 3.4.0.beta3 mit externer Datenbank dazu führt, dass Backups fehlschlagen.
Ich habe zwei Instanzen 3.4.0.beta3 (Tag): 1) mit Postgres-in-Docker (Standard); 2) mit externem Postgres (lokal selbst gehostet).
Die erste kann sowohl nach Zeitplan als auch manuell ein Backup erstellen:
[2024-12-23 11:11:43] Marking backup as running...
[2024-12-23 11:11:44] Making sure '/var/www/discourse/tmp/backups/default/2024-12-23-111143' exists...
[2024-12-23 11:11:44] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-23 11:11:44] Updating metadata...
[2024-12-23 11:11:44] Dumping the public schema of the database...
[2024-12-23 11:11:44] pg_dump: last built-in OID is 16383
[2024-12-23 11:11:44] pg_dump: reading extensions
[2024-12-23 11:11:44] pg_dump: identifying extension members
[2024-12-23 11:11:44] pg_dump: reading schemas
...
Die zweite schlägt fehl:
[2024-12-21 03:35:21] Marking backup as running...
[2024-12-21 03:35:21] Making sure '/var/www/discourse/tmp/backups/default/2024-12-21-033521' exists...
[2024-12-21 03:35:21] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-21 03:35:21] Updating metadata...
[2024-12-21 03:35:21] Dumping the public schema of the database...
[2024-12-21 03:35:22] pg_dump: error: server version: 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1); pg_dump version: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: error: aborting because of server version mismatch
[2024-12-21 03:35:22] EXCEPTION: pg_dump failed
...
2 „Gefällt mir“
Ich habe gestern ein Upgrade durchgeführt und bestätige, dass die geplanten Backups aufgrund von Versionskonflikten fehlschlagen.
Sie können dies beheben, indem Sie Docker aufrufen und einen neueren postgresql-client installieren.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 „Gefällt mir“
Hallo Leute,
Ich bin jetzt auf verschlüsselte PostGre DBs in RDS umgestiegen und habe gestern dasselbe getan (wie in den vorherigen Schritten beschrieben (Backup erstellen, app.yml bearbeiten, neu erstellen, …) und es hat gestern funktioniert.
Heute habe ich das mit PROD versucht und jetzt bekomme ich diese Fehlermeldung 
Erstelle fehlende Funktionen im discourse_functions Schema…
Stelle die Dump-Datei wieder her… (das kann eine Weile dauern)
SET
SET
SET
FEHLER: unbekannter Konfigurationsparameter „transaction_timeout“
AUSNAHME: psql fehlgeschlagen: FEHLER: unbekannter Konfigurationsparameter „transaction_timeout“
Habe das mit DBeaver direkt in der DB versucht, und dort bekomme ich dieselbe Fehlermeldung (selbst für diese Datenbank, die gestern einwandfrei funktionierte.
Die Backups waren in beiden Fällen aktuell.
Hast du über Nacht etwas geändert? 
Danke und Grüße,
WS
Hallo,
ich habe den Dump, der in der Sicherungsdatei erstellt wird, überprüft:
Er enthält dies oben:
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;
Der Parameter transaction_timeout ist hier seltsam 
da
transaction_timeout wurde in PostgreSQL 17 hinzugefügt.
wie hier angegeben:
https://pgpedia.info/t/transaction_timeout.html
Ich brauche Hilfe 
Danke!
Viele Grüße,
Wurzelseppi
Gibt es eine Möglichkeit, dieses postgresql-client-Update als automatisierten Teil eines Rebuilds durchzuführen, indem die Container-YAML geändert wird?