C’è da qualche parte una nota che indica quali versioni di PostgreSQL sono supportate?
Sarebbe utile avere una lista per ogni versione di Discourse rilasciata, specialmente se una versione di PostgreSQL non è più supportata.
Postgres è incluso nel container Docker per Discourse, quindi generalmente non richiede intervento. Il team di Discourse aggiorna la versione di Postgres man mano che escono nuove release, dopo averle adeguatamente testate. L’ultimo aggiornamento è stato alla versione 13. Puoi vedere i dettagli di questo aggiornamento qui:
3 Mi Piace
Bene, non tutti stanno utilizzando il database PostgreSQL incluso.
La documentazione di installazione corrente elenca Postgres 10+ come versione richiesta:
Detto questo, le uniche configurazioni ufficialmente supportate utilizzano container Docker.
2 Mi Piace
Sì, le versioni di PostgreSQL che sono “supportate” (da una prospettiva di build Docker, non tutte “fortemente supportate”) sono elencate nella directory templates di discourse_docker.
Detto questo, è altamente consigliato passare alla versione più recente di PostgreSQL, attualmente la versione 13, non appena possibile.
Tuttavia, se stai eseguendo Discourse su un host dove non è possibile utilizzare l’ultima versione a causa di alcuni vincoli locali nella tua organizzazione, la directory templates di discourse_docker è un buon punto di partenza per fare ricerche.
4 Mi Piace
Controllo dopo tre anni: il template Docker dice ancora PG_MAJOR=13, ma ci sono nuove versioni di PostgreSQL: 14 dal 2021, 15 dal 2022 e 16 dal 2023.
Quindi la raccomandazione è ancora di usare la versione 13 (che andrà in EOL nel 2025) piuttosto che l’ultima versione di PostgreSQL 16 (che andrà in EOL nel 2028)?
Sì, esatto.
Abbiamo alcuni siti che eseguono già la versione 15 e dovremmo aggiornare dalla 13 l’anno prossimo.
1 Mi Piace
Domanda: qual è lo stato attuale qui? Sto eseguendo un database pg esterno e vorrei aggiornare il server del database da 13. Postgres 16 è stato rilasciato il 14/09/2023. Può essere utilizzato con Discourse? Saranno necessari passaggi di migrazione per il database stesso? (oltre ai passaggi di migrazione globali sul lato server)
PostgreSQL 13 è ancora la versione ufficialmente supportata, con la versione 13.15 rilasciata il mese scorso e ancora supportata.
Abbiamo un buon numero di siti che eseguono la versione 15, ed è una versione funzionante nota per la quale prevediamo di fornire un aggiornamento per gli utenti self-hosted in futuro.
La versione 16 non è ampiamente testata al di fuori delle macchine degli sviluppatori, ma se ti senti avventuroso e vuoi provarla per vedere se qualcosa si rompe, facci sapere come va!
1 Mi Piace
Discourse fa qualcosa di insolito con Postgres che implicherebbe che gli aggiornamenti a nuove versioni di Postgres potrebbero non funzionare con un semplice dump e ripristino?
Riportare in alto questo thread per vedere se c’è un motivo per provare ad aggiornare a PostgreSQL 15 invece che a 16 o 17?
E quando dovremmo aspettarci di aggiornare il PostgreSQL
Ciao ragazzi, mi sono appena trasferito su AWS RDS PostGre 16.4 e sembra che funzioni.
Sono sulla versione di discourse 3.4.0.beta3-dev
Non ho ancora premuto tutti i pulsanti 
, ma la bacheca stessa sembra funzionare, ma…
Non riesco a creare backup, a causa di
[2024-12-13 08:36:07] Assicurarsi che '/var/www/discourse/tmp/backups/default/2024-12-13-083607' esista...
[2024-12-13 08:36:07] Assicurarsi che '/var/www/discourse/public/backups/default' esista...
[2024-12-13 08:36:07] Aggiornamento dei metadati...
[2024-12-13 08:36:07] Dumping dello schema pubblico del database...
[2024-12-13 08:36:08] pg_dump: errore: versione del server: 16.4; versione di pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: errore: interruzione a causa di mancata corrispondenza della versione del server
[2024-12-13 08:36:08] ECCEZIONE: pg_dump fallito
La cosa strana è che sono riuscito effettivamente a importare i dati con i meccanismi interni:
Quello che ho fatto:
- Configurato il db (utente, database, concessioni)
- Configurato le impostazioni in app.yml
- Creato un backup da discourse
- Ricostruito l’app (la migrazione del db è andata a buon fine → il db è vuoto quindi)
- Ripristinato il backup dall’interno del container (launcher enter app, discourse enable_restore, discourse restore …)
- Finito (tutto è andato a buon fine e tutto sembrava funzionare, finché non ho provato a creare un nuovo backup )
C’è qualche possibilità di affrontare questo problema in qualche modo?
Saluti,
JP
1 Mi Piace
Ok ragazzi, ora le cose si fanno interessanti.
Non lavoravo da qualche giorno e non avevo controllato la nostra nuova bacheca aziendale.
Quando ho controllato oggi, il backup programmato ha funzionato, poi ho provato a fare di nuovo il backup manuale, e quello è fallito 
programmato:
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...
manuale:
[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, qualche idea?
Molto strano 
Confermo che l’aggiornamento a 3.4.0.beta3 con database esterno causa il fallimento del backup.
Ho due istanze 3.4.0.beta3 (tag): 1) con Postgres-in-Docker (predefinito); 2) con Postgres esterno (auto-ospitato localmente).
La prima è in grado di eseguire il backup sia per pianificazione che manualmente:
[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
...
La seconda fallisce:
[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 Mi Piace
Mi sono aggiornato ieri e confermo che i backup pianificati falliscono a causa di una discrepanza di versione.
Puoi risolvere eseguendo il docker e installando un client postgresql più recente.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 Mi Piace
Ciao ragazzi,
Ho effettuato il passaggio a database PostGre crittografati in RDS ora, e stavo facendo la stessa cosa ieri (come ho descritto nei passaggi precedenti (fai backup, modifica app.yml, ricostruisci, …) e ha funzionato ieri.
Oggi ho provato con PROD e ora sto ricevendo questo errore 
Creazione delle funzioni mancanti nello schema discourse_functions…
Ripristino del file di dump… (potrebbe richiedere del tempo)
SET
SET
SET
ERRORE: parametro di configurazione non riconosciuto “transaction_timeout”
ECCEZIONE: psql fallito: ERRORE: parametro di configurazione non riconosciuto “transaction_timeout”
Ho provato con DBeaver direttamente nel DB, e lì sto ricevendo lo stesso errore (anche per quel database, che ieri funzionava alla grande).
I backup erano in entrambi i casi aggiornati.
Hai cambiato qualcosa durante la notte? 
Grazie e saluti,
WS
Ciao,
ho controllato il dump che viene creato nel file di backup:
Include questo in cima
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;
Il parametro transaction_timeout è strano qui 
poiché
transaction_timeout è stato aggiunto in PostgreSQL 17.
come affermato qui:
https://pgpedia.info/t/transaction_timeout.html
Ho bisogno di aiuto 
Grazie!
Saluti,
Wurzelseppi
1 Mi Piace
Esiste un modo per eseguire questo aggiornamento di postgresql-client come parte automatizzata di una ricostruzione modificando lo YAML del container?