Gibt es irgendwo einen Hinweis darauf, welche PostgreSQL-Datenbankversionen unterstützt werden?
Es wäre großartig, wenn es für jede veröffentlichte Discourse-Version eine solche Information gäbe – insbesondere, wenn eine PostgreSQL-Version nicht mehr unterstützt wird.
Postgres ist im Docker-Container für Discourse enthalten, daher ist dies in der Regel ein reibungsloser Prozess. Das Discourse-Team aktualisiert die Postgres-Version, sobald neue Releases erscheinen und diese ordnungsgemäß getestet wurden. Das neueste Upgrade war auf Version 13. Die Details dieses Upgrades finden Sie hier:
Nun, nicht jeder nutzt die mitgelieferte PostgreSQL-Datenbank.
Die aktuelle Installationsdokumentation listet Postgres 10+ als erforderliche Version auf:
Trotzdem sind die einzigen offiziell unterstützten Konfigurationen die Verwendung von Docker-Containern.
Ja, die PostgreSQL-Versionen, die „unterstützt
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.
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!
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:
)Gibt es eine Möglichkeit, das irgendwie anzugehen?
Grüße,
JP
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
...
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
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?