Problèmes avec la mise à niveau de postgres 15

Bonjour,
J’ai lancé une mise à jour après sans doute un an, ce qui a mené au passage de pg 13 à 15.

J’essaye de lancer la commande donnée avec mon propre LC_LANG mais ça ne fonctionne pas, j’ai `FATAL: data directory “/shared/postgres_data” does not exist`. Et effectivement il n’existe pas… Quelqu’un a une idée?

Il devrait y avoir un /shared/postgres_old.

Changer votre LC_LANG est probablement une mauvaise idée.

J’ai en fait rencontré la même erreur que vous : « /bin/bash: warning: setlocale: LC_ALL: cannot change locale » lorsque j’ai essayé ma commande launch rebuild app, ce qui m’a finalement conduit à ce post. Avez-vous réussi à le résoudre au final ? Les commandes docker run ne m’ont conduit qu’à plus de problèmes, comme indiqué ci-dessus.

J’ai ajouté un mappage \-v /var/discourse/shared/standalone:/shared et maintenant j’ai un peu avancé. C’est bizarre que ce ne soit pas là cependant. Le problème est peut-être que mon « app » est toujours bloquée à une version quelque part en 2024 et que la « reconstruction » ne fonctionne pas. Juste une supposition…

J’avais ceci dans mon app.yml et cela fonctionnait bien :

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

Je voulais dire LANG et non LC_LANG. Le problème est que si je reviens à autre chose maintenant, il est « trop tard ». J’ai essayé en_US.UTF_8 et rien, la reconstruction échoue toujours.

Si vous n’avez pas de sauvegarde actuelle et que vous ne pouvez pas redémarrer votre ancien conteneur, je passerais au modèle PG13 et obtiendrais une configuration fonctionnelle, puis je ferais une sauvegarde, puis je configurerais un nouveau serveur et restaurerais la sauvegarde là-bas. Vous pouvez le configurer avec n’importe quel langage que vous aimez lorsqu’il s’agit d’une base de données vide, puis effectuer la restauration (et peut-être que le langage sera converti comme par magie ?).

Le déplacement vers un nouveau serveur garantit que vous ne ferez pas planter votre serveur existant.

1 « J'aime »

Malheureusement, je suis déjà dans un état planté. J’ai des sauvegardes, mais je ne peux pas les restaurer car le changement de version est trop important et il y a des problèmes de dépendances avec les gemmes. Je ne peux pas non plus revenir à l’ancienne version car le lanceur la tire automatiquement, ce qui est un peu triste à mon avis.

Avec LC_ALL, j’obtiens :

/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

Si je supprime LC_ALL, alors le ./launcher rebuild app s’arrête à :

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”

Avec la ligne docker « manuelle » mentionnée dans le message initial, j’ai également dû lier des éléments dans /etc/postgresql à /var/… car certains fichiers étaient manquants et j’ai finalement obtenu la même erreur que ci-dessus.

Je vais essayer une nouvelle installation et restaurer là-bas.

Je doute qu’il soit vrai que le changement de version soit trop important. Avez-vous configuré un nouveau serveur et essayé de restaurer cette sauvegarde ? J’ai restauré une sauvegarde de plusieurs années antérieure au site sur lequel elle a été restaurée. Je suis presque certain que cela fonctionnera. Je déplace des sites vers de nouveaux serveurs plusieurs fois par mois. La seule fois où il y a eu un problème, c’est lorsqu’il y avait un index corrompu, ce que je n’ai pas vu depuis un bon moment.

Avez-vous essayé de renommer postgres_old en postgres_data et

./launcher start app

Oh. C’est une bonne idée ! C’est pour ça que je devrais lire l’intégralité du message avant de répondre. :slight_smile:

Je peux confirmer qu’une nouvelle installation casse également avec LC_ALL défini, de la même manière que montré ci-dessus (\FILE_SEPERATOR\ …). Cependant, sans LC_ALL, cela fonctionne.

J’ai pu restaurer ma sauvegarde avec une nouvelle installation propre sur la dernière version master, merci. Résoudre ces problèmes restera un mystère…

1 « J'aime »

Super !

J’ai déplacé ceci vers un nouveau sujet. Si l’une de mes réponses a été la solution, veuillez la marquer comme telle pour permettre la fermeture automatique de ce sujet.

2 « J'aime »