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?

I actually got the same error than you “/bin/bash: warning: setlocale: LC_ALL: cannot change locale” when I tried my launch rebuild app which led me ultimately to this post, could you solve it in the end? The docker run commands just lead me to more problems, as stated above.

I added a mapping `-v /var/discourse/shared/standalone:/shared` and now I have advanced a bit. It is weird it’s not there though. The problem might be my “app” is still stuck at a version somewhere in 2024 and the “rebuild” does not work. Just a guess… So I had this in my app.yml and it worked fine: env: LC_ALL: fr_BE.UTF-8 LANG: fr_BE.UTF-8 LANGUAGE: fr_BE.UTF-8 I meant LANG and not LC_LANG. The problem is that if I revert to anything else now it’s “too late”. I tried en_US.UTF_8 and nothing, the rebuild always fails.

If you don’t have a current backup and can’t restart your old container, then I’d switch to the PG13 template and get a working setup, then make a backup, then set up a new server and restore the backup there. You can set it up with whatever language you like when it’s an empty database and then do the restore (and maybe the language will magically get converted?). Moving to a new server ensures that you don’t crash your existing server.

Sadly I’m already in a crashed state. I do have backups but I can’t restore them as the version change is too big and there are problems of dependencies with gem. I also can’t go back to the old version as launcher pulls automatically, a bit sad imo. With LC_ALL I get: /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 ` ' from /usr/local/bin/pups:25:in `load' from /usr/local/bin/pups:25:in ` ' 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 If I remove LC_ALL, then the “./launcher rebuild app” stops at : 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” With the “manual” docker line mentioned in the top post, I also had to link stuff in /etc/postgresql to /var/… as some files were missing and eventually got the same error than above. I’ll try a new install and restore there.

[image] tbarbette: Sadly I’m already in a crashed state. I do have backups but I can’t restore them as the version change is too big and there are problems of dependencies with gem. I doubt that it’s true that the version change is too big. Have you set up a new server and tried to restore that backup? I’ve restored a backup several years older than the site where it was restored. I’m fairly certain that it’ll work. I move sites to new servers several times a month. the only time there’s been an issue is when there was a corrupt index, which I haven’t seen in quite a while. [image] tbarbette: I also can’t go back to the old version as launcher pulls automatically, a bit sad imo. Have you tried renaming postgres_old to postgres_data and ./launcher start app [image] tbarbette: I’ll try a new install and restore there. Oh. That’s a good idea! That’s why I should read the whole post before replying. :slight_smile:

I can confirm new install also break with LC_ALL set, in the same way than shown above (_FILE_SEPERATOR_ …). However without LC_ALL it’s fine. I could restore my save with a new fresh install on the latest master, thanks. Fixing those issues will stay a mistery…

Great! I moved this to a new topic. If one of my responses was the solution, please mark it so to allow this to get auto-closed

Trouble with postgres 15 upgrade

Product Support Self-hosting

pfaffman (Jay Pfaffman) December 2, 2025, 3:32pm 2

There should be a /shared/postgres_old.

Changing your LC_LANG is likely a bad idea.

Topic		Replies	Views
Postgresql upgrade error with locale on rebuild Self-hosting	7	1803	May 16, 2018
Postgres error upgrading from 3.3 to 3.4 caused by locale issues Bug	8	888	January 7, 2025
Unable to upgrade to PostgreSQL 15/ Self-hosting	12	949	June 3, 2025
Major woes upgrading from 1.6.0 to 1.8.0 -- broken site Self-hosting	9	3189	March 29, 2017
PostgreSQL 15 update Announcements	107	8691	October 22, 2025

Trouble with postgres 15 upgrade

Related topics