Is there somewhere a note, which postgresql db versions are supported?
Would be great to have something for each released discourse version - especially if a postgresql version is no longer supported.
Postgres is bundled in with the Docker container for Discourse, so this is generally hands-off. The Discourse team upgrades the Postgres version as new releases come out and they are properly tested. The most recent upgrade was to version 13. You can see the details of that upgrade here:
3 curtidas
Well, not everyone is using the bundled postgres db.
The current install doc lists Postgres 10+ as the required version:
https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
That said, the only officially supported setups are using Docker containers.
2 curtidas
Yes, the versions of postgres which are “supported” (from a docker build perspective, not all “strongly supported”) are listed in the templates directory of discourse_docker
Having said that, it is highly recommended to move to the latest version of postgres, currently version 13, as soon as you can.
However, if you are running Discourse on a host where you cannot run the latest version because of some local constraint in your organization; the discourse_docker templates directory is a good place to research.
4 curtidas
Verificando três anos depois: o modelo docker ainda diz PG_MAJOR=13, mas existem novas versões do PostgreSQL: 14 de 2021, 15 de 2022 e 16 de 2023.
Portanto, a recomendação ainda é usar a versão 13 (que terá EOL em 2025) em vez do PostgreSQL 16 mais recente (que terá EOL em 2028)?
Sim, exatamente.
Temos alguns sites já rodando a versão 15 e devemos atualizar da 13 no ano que vem.
1 curtida
Pergunta: qual é o status atual aqui? Estou executando um banco de dados pg externo e gostaria de atualizar o servidor de banco de dados a partir da versão 13. O PostgreSQL 16 foi lançado em 14/09/2023. Ele pode ser usado com o Discourse? Haverá alguma etapa de migração necessária para o próprio banco de dados? (além das etapas de migração globais do lado do servidor)
O PostgreSQL 13 ainda é a versão oficialmente suportada, com a versão 13.15 tendo sido lançada no mês passado e ainda suportada.
Temos um bom número de sites executando a versão 15, e essa é uma versão conhecida e funcional para a qual planejamos enviar uma atualização para usuários auto-hospedados eventualmente.
A versão 16 não é amplamente testada fora das máquinas dos desenvolvedores, mas se você se sentir aventureiro e quiser experimentá-la e ver se algo quebra, nos diga como foi!
1 curtida
O Discourse faz algo fora do comum com o Postgres que implicaria que atualizações para novas versões do Postgres podem não funcionar com um simples dump e restore?
Aumentando este tópico para ver se há um motivo para tentar atualizar para PostgreSQL 15 em vez de 16 ou 17?
E quando devemos esperar atualizar o PostgreSQL?
Olá pessoal, acabei de migrar para AWS RDS PostGre 16.4 e parece que está funcionando.
Estou na versão do Discourse 3.4.0.beta3-dev
Ainda não apertei todos os botões 
, mas o painel em si parece estar funcionando, mas…
Não consigo criar backups, devido a
[2024-12-13 08:36:07] Verificando se '/var/www/discourse/tmp/backups/default/2024-12-13-083607' existe...
[2024-12-13 08:36:07] Verificando se '/var/www/discourse/public/backups/default' existe...
[2024-12-13 08:36:07] Atualizando metadados...
[2024-12-13 08:36:07] Despejando o esquema público do banco de dados...
[2024-12-13 08:36:08] pg_dump: erro: versão do servidor: 16.4; versão do pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: erro: abortando devido à incompatibilidade de versão do servidor
[2024-12-13 08:36:08] EXCEPTION: falha ao executar pg_dump
A coisa estranha é que eu consegui importar os dados com mecanismos internos:
O que eu fiz:
- Configurei o banco de dados (usuário, banco de dados, permissões)
- Configurei as coisas em app.yml
- Criei um backup dentro do Discourse
- Reconstruí o aplicativo (a migração do banco de dados foi bem-sucedida → o banco de dados fica vazio então)
- Restaurei o backup de dentro do contêiner (launcher enter app, discourse enable_restore, discourse restore …)
- Concluído (tudo bem-sucedido, e tudo parecia estar funcionando, até que tentei criar um novo backup )
Alguma chance de resolver isso de alguma forma?
Saudações,
JP
1 curtida
Ok pessoal, agora está ficando interessante.
Não trabalhei por alguns dias e não verifiquei nosso novo painel da empresa.
Quando verifiquei hoje, o backup agendado funcionou, então tentei fazer o backup manual novamente, e falhou 
agendado:
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...
manual:
[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, alguma ideia?
Muito estranho 
Confirmo que a atualização para 3.4.0.beta3 com banco de dados externo falha no backup.
Tenho duas instâncias 3.4.0.beta3 (tag): 1) com Postgres-in-Docker (padrão); 2) com Postgres externo (auto-hospedado localmente).
A primeira consegue fazer backup tanto por agendamento quanto manualmente:
[2024-12-23 11:11:43] Marcando backup como em execução...
[2024-12-23 11:11:44] Garantindo que '/var/www/discourse/tmp/backups/default/2024-12-23-111143' exista...
[2024-12-23 11:11:44] Garantindo que '/var/www/discourse/public/backups/default' exista...
[2024-12-23 11:11:44] Atualizando metadados...
[2024-12-23 11:11:44] Despejando o esquema público do banco de dados...
[2024-12-23 11:11:44] pg_dump: último OID interno é 16383
[2024-12-23 11:11:44] pg_dump: lendo extensões
[2024-12-23 11:11:44] pg_dump: identificando membros da extensão
[2024-12-23 11:11:44] pg_dump: lendo esquemas
...
A segunda falha:
[2024-12-21 03:35:21] Marcando backup como em execução...
[2024-12-21 03:35:21] Garantindo que '/var/www/discourse/tmp/backups/default/2024-12-21-033521' exista...
[2024-12-21 03:35:21] Garantindo que '/var/www/discourse/public/backups/default' exista...
[2024-12-21 03:35:21] Atualizando metadados...
[2024-12-21 03:35:21] Despejando o esquema público do banco de dados...
[2024-12-21 03:35:22] pg_dump: erro: versão do servidor: 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1); versão do pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: erro: abortando devido à incompatibilidade de versão do servidor
[2024-12-21 03:35:22] EXCEÇÃO: falha ao executar pg_dump
...
2 curtidas
Atualizei ontem e confirmo que os backups agendados falham devido à incompatibilidade de versão.
Você pode corrigir entrando no docker e instalando um postgresql-client mais recente.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 curtidas
Olá pessoal,
Mudei para bancos de dados PostGre criptografados em RDS agora, e estava fazendo a mesma coisa ontem (como descrevi nos passos anteriores (fazer backup, editar app.yml, reconstruir, …) e estava funcionando ontem.
Hoje tentei isso com o PROD e agora estou recebendo este erro 
Criando funções ausentes no esquema discourse_functions…
Restaurando arquivo de dump… (isso pode levar um tempo)
SET
SET
SET
ERRO: parâmetro de configuração não reconhecido "transaction_timeout"
EXCEPTION: psql falhou: ERRO: parâmetro de configuração não reconhecido "transaction_timeout"
Tentei isso diretamente com o DBeaver no banco de dados, e lá estou recebendo o mesmo erro (mesmo para aquele banco de dados, que funcionou perfeitamente ontem.
Os backups estavam atualizados em ambos os casos.
Você mudou alguma coisa durante a noite? 
Obrigado e saudações,
WS
Olá,
verifiquei o dump que está sendo feito no arquivo de backup:
Ele inclui isto no topo
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;
O parâmetro transaction_timeout é estranho aqui 
como
transaction_timeout foi adicionado no PostgreSQL 17.
declarado aqui:
https://pgpedia.info/t/transaction_timeout.html
Preciso de ajuda 
Obrigado!
Atenciosamente,
Wurzelseppi
Existe uma maneira de fazer esta atualização do postgresql-client como parte automatizada de uma reconstrução, modificando o YAML do contêiner?