NOTA: Non sono sicuro del motivo, ma l’aggiornamento a PostgreSQL 18 disabilita i checksum dei dati nativi. I checksum dei dati PostgreSQL sono una funzionalità predefinita e sembra molto insolito disabilitarli.
PR per non disabilitare i controlli di integrità dei dati (abilitati per impostazione predefinita): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
E onestamente è meglio che dover avere 20 GB liberi per quell’ora che ti servono una volta all’anno, lol
Forse questo dovrebbe essere l’approccio consigliato per risparmiare alberi e acqua. 
Solo per confermare, non sto usando PostgreSQL fornito da Discourse e Discourse stesso non richiede ancora PG18, giusto? Quindi non sono (ancora) tenuto ad aggiornare a PG18.
Buon punto. Ma l’altro aspetto è che le versioni LTS vengono rilasciate ogni paio di anni, quindi non è una cattiva idea procedere con l’aggiornamento allo stesso tempo.
Hai sicuramente ancora tempo. Hanno spinto per… ehm, un rilascio piuttosto veloce dopo l’aggiornamento a causa di una funzionalità richiesta, ma probabilmente puoi aspettare fino a un anno. Tengo d’occhio il repository discourse_docker. A un certo punto inizieranno a parlare della rimozione del supporto per PG15; non è particolarmente rumoroso ed è un modo semplice per restare aggiornati sulle modifiche interne.
2 Mi Piace
Funzionava perfettamente sulla mia installazione di Pi 5, due ricostruzioni e via.
7 Mi Piace
Abbiamo qualche benchmark, a proposito?
Questo potrebbe incoraggiare altri a seguire le nostre intraprendenti orme più rapidamente.
La mia AI di ricerca web gratuita mi dice:
Per un’applicazione Rails tipica, il passaggio da PostgreSQL 15 a 18 può garantire ~10–25% di prestazioni di query più veloci senza modifiche al codice, e fino al 40% in specifici pattern di query se si sfruttano le nuove funzionalità di indicizzazione e pianificazione.
Se è vero, è un aggiornamento piuttosto significativo! 
7 Mi Piace
Solo per confermare che tutto è andato alla perfezione nella nostra istanza self-hosted. Grazie per questo aggiornamento e teneteci aggiornati.
5 Mi Piace
Vero, ma il nostro obiettivo è un meccanismo di aggiornamento semplice e trasparente. Ci sono vantaggi in entrambi i casi.
Direi di fare ciò che ti sembra più comodo e non avere paura di personalizzare i template in discourse_docker in base alle tue esigenze. Ovviamente la chiave è testare prima e avere un piano di rollback.
Sulla nostra piattaforma hostata intendiamo eseguire più test e benchmarking prima di abilitarli, e quindi li ho disabilitati anche in discourse_docker per allineare la configurazione. Non è strettamente necessario disabilitarli (internamente utilizziamo solo la parte del contenitore web di discourse_docker) e non sarei contrario ad abilitarli.
Un potenziale problema è che pg_upgrade non funzionerà se le directory dei dati vecchia e nuova hanno impostazioni di checksum diverse. Il processo dovrebbe essere quello di arrestare il server PG15, eseguire pg_upgrade per convertirlo in PG18 senza checksum, eseguire pg_checksums per abilitare i checksum e quindi avviare PG18. Questo non è un problema quando si esegue un dump e restore (come in questo aggiornamento) ma è qualcosa a cui fare attenzione.
Nota che i checksum dei dati sono disponibili da Postgres 9.3 ma fino ad ora sono stati disabilitati per impostazione predefinita. Postgres 19 includerà anche la possibilità di abilitarli/disabilitarli online.
Al momento no. La maggior parte delle funzionalità di Discourse utilizza l’adattatore PostgreSQL di Rails per comunicare con il DB, ma il backup/restore utilizza pg_dump e psql nel contenitore web. Al momento stiamo installando sia i client PG15 che PG18 per abilitare il backup/restore utilizzando entrambe queste versioni, ma in un momento futuro rimuoveremo PG15.
Il fattore trainante è stato il passaggio al nuovo provider locale integrato. Stiamo lavorando verso un aggiornamento del sistema operativo sulla nostra piattaforma hostata e vogliamo interrompere l’accoppiamento con glibc.
3 Mi Piace
Gestisco il mio PostgreSQL in modo indipendente dal container. Qual è l’hash Git consigliato su cui passare per la versione pg18?
1 Mi Piace
e7f1201 ha aggiunto il client PG18 all’immagine web per garantire la compatibilità dei backup. Se non stai utilizzando nessuno dei componenti del server Postgres di discourse_docker, questa è la revisione più antica che dovresti utilizzare per PG18.
1 Mi Piace
Parlavamo di un aggiornamento o due fa.
D’accordo. Il mio punto era semplicemente che non è meno supportato poter ripristinare un backup postgres più vecchio su una versione più recente. Il meccanismo di aggiornamento in-place funziona in modo incredibile per la stragrande maggioranza delle persone, ma quando qualcosa va storto, è difficile sapere cosa fare (principalmente perché accade così raramente).
2 Mi Piace
Se può essere d’aiuto a qualcuno, per quei momenti in cui la console SSH rimane immobile e inizia a farsi sentire quella fredda sudorazione da panico…
Ho eseguito questo in un altro terminale per tenere d’occhio i progressi:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Che aggiorna ogni 10 secondi e ti mantiene sano di mente
La mia migrazione di 35 GB ha richiesto circa 10 minuti.
8 Mi Piace
L’aggiornamento è andato a buon fine con l’installazione standard. Naturalmente, prima ho fatto un backup e lo ho scaricato, nel caso qualcosa fosse andato storto 
3 Mi Piace
Belino. Aggiungerei un free -h a questo - l’esaurimento della memoria è un problema abbastanza comune.
L’unica cosa riguardo a ‘watch’ o effettivamente a ‘top’ è che continua a ricaricarsi, quindi potresti perdere qualcosa. Se ti esaurisce qualcosa e l’aggiornamento fallisce, dopo pochi secondi hai perso il record. Quindi tendo a eseguire qualcosa di più simile a un while - forse così:
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 Mi Piace
Posso segnalare un successo . . . per metà della mia configurazione multisito. Il sito predefinito è stato migrato come previsto, ma il sito secondario sembrava una nuova installazione. Fortunatamente, non è difficile ripristinare un backup. Ho un altro server che utilizzo per i clienti e sto pensando di creare una nuova Droplet e ripristinare i siti dai backup per eseguire questo aggiornamento. Questo è uno dei rischi dell’utilizzo di un’installazione non standard, immagino.
1 Mi Piace
Il tuo contenitore dati era un contenitore dati standard? Mi chiedevo se avrebbe spostato solo un database o tutti quelli nel cluster. Sembra che tu abbia risposto alla mia domanda!
Quello che ho fatto finora è stato spostare manualmente ogni database dal vecchio cluster a quello nuovo, quindi modificare manualmente discourse.conf per puntare al nuovo database e infine eseguire una ricostruzione per far puntare l’intero contenitore multisite al nuovo cluster (su una macchina o porta diversa).
1 Mi Piace
Sì. Certo, non posso dire di non aver combinato un guaio nella mia configurazione. 
Avevo previsto di eseguire un rsync dei dati di PostgreSQL per fare un upgrade di qn e verificare con certezza se il processo spostava solo il database di Discourse o l’intero cluster, ma sembra che tu abbia già risposto alla mia domanda e che sarà chiaro se guardo il codice.
2 Mi Piace
Ho due domande qui:
- Abbiamo montato un blocco di archiviazione aggiuntivo sul server di test. Ma l’aggiornamento di PostgreSQL fallisce perché il controllo dello spazio controlla solo il disco principale. C’è un modo per bypassare il controllo dello spazio?
- Per il nostro sito di produzione, utilizziamo Google Cloud SQL. C’è qualcosa che dobbiamo sapere prima dell’aggiornamento tramite Google Cloud?