Problemas com a atualização do postgres 15

Suporte Instalação
1

Olá,
Eu iniciei uma atualização depois de provavelmente um ano, o que levou a migração do pg 13 para o 15.

Estou tentando executar o comando fornecido com meu próprio LC_LANG, mas não funciona, recebo FATAL: data directory “/shared/postgres_data” does not exist. E, de fato, ele não existe… Alguém tem alguma ideia?

2

Deveria haver um /shared/postgres_old.

Mudar seu LC_LANG é provavelmente uma má ideia.

3

Eu, na verdade, tive o mesmo erro que você, “/bin/bash: warning: setlocale: LC_ALL: cannot change locale”, quando tentei meu launch rebuild app, o que me levou a este post. Você conseguiu resolver no final? Os comandos docker run apenas me levaram a mais problemas, como afirmado acima.

4

Adicionei um mapeamento \-v /var/discourse/shared/standalone:/shared e agora avancei um pouco. É estranho que não esteja lá, no entanto. O problema pode ser que meu “app” ainda esteja preso em alguma versão de 2024 e o “rebuild” não funcione. Apenas um palpite…

Então eu tinha isto no meu app.yml e funcionava bem:

env:
  LC_ALL: fr_BE.UTF-8
  LANG: fr_BE.UTF-8
  LANGUAGE: fr_BE.UTF-8

Eu quis dizer LANG e não LC_LANG. O problema é que se eu reverter para qualquer outra coisa agora, é “tarde demais”. Eu tentei en_US.UTF_8 e nada, o rebuild sempre falha.

5

Se você não tem um backup atual e não consegue reiniciar seu contêiner antigo, eu mudaria para o modelo PG13 e obteria uma configuração funcional, depois faria um backup, e então configuraria um novo servidor e restauraria o backup lá. Você pode configurá-lo com a linguagem que quiser quando for um banco de dados vazio e depois fazer a restauração (e talvez a linguagem seja convertida magicamente?).

Mover para um novo servidor garante que você não trave seu servidor existente.

6

Infelizmente, já estou em um estado travado. Eu tenho backups, mas não consigo restaurá-los, pois a mudança de versão é muito grande e há problemas de dependência com gems. Também não consigo voltar para a versão antiga, pois o launcher puxa automaticamente, o que é um pouco triste, na minha opinião.

Com LC_ALL, eu obtenho:

/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups.rb
/usr/local/bin/pups --stdin
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (fr_BE.UTF-8)
I, [2025-12-02T15:46:29.638999 #1]  INFO -- : Reading from stdin
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/cli.rb:59:in `split': invalid byte sequence in US-ASCII (ArgumentError)

    split = conf.split("_FILE_SEPERATOR_")
                       ^^^^^^^^^^^^^^^^^^
    from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/cli.rb:59:in `run'
    from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/bin/pups:9:in `<top (required)>'
    from /usr/local/bin/pups:25:in `load'
    from /usr/local/bin/pups:25:in `<main>'

bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
19a63b958021df0ecbc7e21bfea95f1c5ef7b039efd669b5d4af48b05d397a58

Se eu remover o LC_ALL, então o ./launcher rebuild app para em:

Performing Consistency Checks

Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             ok
Checking for not-null constraint inconsistencies            ok
Creating dump of global objects                             ok
Creating dump of database schemas                           ok

lc_collate values for database “template1” do not match:  old “fr_BE.UTF-8”, new “en_US.UTF-8”

Com a linha docker “manual” mencionada na postagem principal, eu também tive que vincular coisas em /etc/postgresql para /var/… pois alguns arquivos estavam faltando e, finalmente, obtive o mesmo erro que acima.

Vou tentar uma nova instalação e restaurar lá.

7

Duvido que seja verdade que a mudança de versão seja muito grande. Você configurou um novo servidor e tentou restaurar esse backup? Eu restaurei um backup vários anos mais antigo do que o site onde foi restaurado. Tenho certeza de que funcionará. Eu movo sites para novos servidores várias vezes por mês. A única vez que houve um problema foi quando havia um índice corrompido, o que não vejo há um bom tempo.

Você tentou renomear postgres_old para postgres_data e

./launcher start app

Ah. Essa é uma boa ideia! É por isso que eu deveria ler a postagem inteira antes de responder. :slight_smile:

8

Confirmo que uma nova instalação também falha com LC_ALL definido, da mesma forma que mostrado acima (\FILE_SEPERATOR\ …). No entanto, sem LC_ALL está tudo bem.

Consegui restaurar meu backup com uma nova instalação limpa na última versão master, obrigado. Resolver esses problemas continuará sendo um mistério…

9

Ótimo!

Movi isto para um novo tópico. Se uma das minhas respostas foi a solução, por favor, marque-a como tal para permitir que este tópico seja fechado automaticamente.