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.