OBSERVAÇÃO: Não tenho certeza do motivo, mas a atualização para o PostgreSQL 18 desativa as verificações de integridade de dados nativas. As verificações de integridade de dados do PostgreSQL são um recurso padrão e parece muito incomum desativá-las.
PR para não desativar as verificações de dados (ativadas por padrão): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
E é melhor do que ter que manter 20 GB livres por aquela única hora em que você vai precisar durante o ano todo kkk
Talvez essa deva ser a abordagem recomendada para economizar árvores e água. 
Só para confirmar, não estou usando o PostgreSQL fornecido pelo Discourse e o próprio Discourse ainda não exige o PG18, correto? Então, não sou obrigado (ainda) a fazer a atualização para o PG18.
Bom ponto. Mas o outro aspecto é que as versões LTS saem a cada dois anos, então não é uma má ideia fazer isso ao mesmo tempo.
Você tem bastante tempo. Eles pressionaram por… hum, alguma versão bem rápido após a atualização devido a algum recurso que era necessário, mas você provavelmente pode esperar até um ano. Eu acompanho o repositório discourse_docker. Em algum ponto eles começarão a falar sobre remover o suporte ao PG15; não é especialmente barulhento e é uma maneira fácil de se manter atualizado com as mudanças internas.
2 Curtiram
Funcionou perfeitamente na minha instalação do Pi 5, duas reconstruções e pronto.
6 Curtiram
Por falar nisso, temos algum benchmark?
Isso pode incentivar outros a seguir nossos passos intrepides mais cedo.
Minha IA de busca web gratuita está me dizendo:
Para um aplicativo Rails típico, migrar do PostgreSQL 15 → 18 pode resultar em ~10–25% de melhoria no desempenho das consultas sem alterações no código, e até 40% em padrões de consulta específicos, se você aproveitar os novos recursos de indexação e do planejador.
Se for verdade, essa é uma atualização bem interessante! 
7 Curtiram
Apenas para confirmar que tudo ocorreu sem problemas em nossa instância auto-hospedada. Obrigado pela atualização e mantenha-nos informados.
4 Curtiram
É verdade, mas nosso objetivo é um mecanismo de upgrade simples e transparente. Existem vantagens em ambas as abordagens.
Diria que faça o que te deixar mais confortável e não tenha medo de personalizar os templates no discourse_docker conforme suas necessidades. Obviamente, o mais importante é testar primeiro e ter um plano de rollback.
Em nossa plataforma hospedada, pretendemos fazer mais testes e benchmarks antes de ativá-las, e por isso as desativei no discourse_docker também para alinhar a configuração. No entanto, não é estritamente necessário desativá-las (usamos internamente apenas a parte do container web do discourse_docker) e eu não me oporia a ativá-las.
Um possível problema é que o pg_upgrade não funcionará se os diretórios de dados antigo e novo tiverem configurações de checksum diferentes. O processo seria: desligar o servidor PG15, executar o pg_upgrade para convertê-lo para PG18 sem checksums, executar o pg_checksums para habilitar as checksums e, em seguida, iniciar o PG18. Isso não é um problema ao fazer dump e restore (como nesta atualização), mas é algo a se observar.
Note que as checksums de dados estão disponíveis desde o Postgres 9.3, mas até agora estavam desativadas por padrão. O Postgres 19 também incluirá a capacidade de habilitá-las/desabilitá-las online.
Não, não neste momento. A maioria das funcionalidades do Discourse usa o adaptador PostgreSQL do Rails para se comunicar com o banco de dados, mas o backup/restore usa pg_dump e psql no container web. Atualmente, estamos instalando os clientes PG15 e PG18 para permitir backup/restore usando ambas as versões, mas em algum momento no futuro removeremos o PG15.
O fator determinante foi a mudança para o novo provedor de locale integrado. Estamos trabalhando em um upgrade do SO em nossa plataforma hospedada e queremos quebrar o acoplamento com a glibc.
1 Curtiu
Eu gerencio meu PostgreSQL de forma independente do contêiner. Qual é o hash do Git recomendado para o qual devo mudar para o pg18?
1 Curtiu
e7f1201 adicionou o cliente PG18 à imagem web para compatibilidade de backup. Se você não estiver usando nenhum dos componentes do servidor Postgres do discourse_docker, esta é a revisão mais antiga que você deve usar para PG18.
1 Curtiu
Eu estava falando sobre uma ou duas atualizações atrás.
Concordo. Meu ponto era apenas que não há menos suporte para poder restaurar um backup antigo do Postgres em uma versão mais nova. O mecanismo de atualização in-place funciona incrivelmente bem para a grande maioria das pessoas, mas quando algo dá errado, é difícil saber o que fazer (principalmente porque isso acontece com tanta rareza).
1 Curtiu
Se ajudar a alguém, para aqueles momentos em que o console SSH fica parado e o suor frio do pânico começa a aparecer…
Rodei isso em outro terminal para acompanhar o progresso:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Que atualiza a cada 10s e mantém você cuerdo
Minha migração de 35GB levou cerca de 10 minutos.
2 Curtiram
A atualização foi concluída sem problemas na instalação padrão. Claro que fiz um backup antes e baixei, caso algo desse errado 
2 Curtiram
Legal. Eu adicionaria um free -h a isso — a falta de memória é um problema comum o suficiente.
A única coisa sobre um ‘watch’ ou, de fato, um ‘top’ é que ele continua atualizando, então você pode perder algo. Se você ficar sem algo e a atualização falhar, alguns segundos depois você perdeu o registro. Então, eu tend a executar algo mais como um while — talvez assim:
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