During upgrade, I was getting
Stopping PostgreSQL 15 database server: mainError: Config owner (postgres:101) and data owner (runit-log:999) do not match, and config owner is not root … failed!
failed!
could not open version file “/shared/postgres_data/PG_VERSION”: Permission denied
Failure, exiting
Which was solved by
sudo ./launcher enter app
and then
chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
I am in an infinite loop, the database updated fine but when I run ./launcher rebuild app it just loops around, the only thing I can see is the following
EDIT: Found this message…
mv: inter-device move failed: '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new'; unable to remove target: Directory not empty
Your installation contains extensions that should be updated
with the ALTER EXTENSION command. The file
update_extensions.sql
when executed by psql by the database superuser will update
these extensions.
Please advise
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
UPGRADE OF POSTGRES COMPLETE
Old 13 database is stored at /shared/postgres_data_old
To complete the upgrade, rebuild again using:
./launcher rebuild app
-------------------------------------------------------------------------------------
Ok so it seems this is the problem here:
These are located at shared/standalone/ and have been moved manually already…
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old': Device or resource busy
mv: inter-device move failed: '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new'; unable to remove target: Directory not empty
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generating locales (this might take a while)...
No solution seem to work. It is so frustrating.
That would be very unusual for someone to simply offer such a service without first being asked.
If you wish to hire someone this is the place to go: Marketplace - Discourse Meta
Our multi-site instance is down after the upgrade. It said:
Your installation contains extensions that should be updated
with the ALTER EXTENSION command. The file
update_extensions.sql
when executed by psql by the database superuser will update
these extensions.
I can’t find the update_extensions.sql file anywhere. Where would it be located?
Check for this
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old': Device or resource busy
mv: inter-device move failed: '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new'; unable to remove target: Directory not empty
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generating locales (this might take a while)...
It was me. I offer help when it appears that someone is in a situation that is going to be hard to resolve with help here.
Curiosity question.
Is there a standard or strategy related to key component upgrades, like Postgres?
I see Postgres 13 support ran through 11/25, and that 15 goes through 2027, and the current version is 17.
Really just looking to learn and understand. Changing db versions is generally a big deal and heavy lift.
Thanks!
I’ve been around since postgres 10. They usually upgrade every two releases, though they went from 12 to 13 because it had some improvements that made an early switch worthwhile. I was a little surprised they didn’t go on to 16.
They generally go pretty smoothly if you’ve got enough disk space and recent docker.
I have reverted back to 13 template until there is a fix, thanks
I have solved the problem I had with the PostgreSQL 13 to 15 upgrade, after restoring the server with the failed upgrade from backups, the following steps worked for me with a PostgreSQL en_GB.UTF-8 locale:
sudo -i
su - discourse
cd /var/discourse
git stash
git stash drop
git pull
./launcher stop app
docker run --rm \
--entrypoint=/bin/bash \
-e LANG='en_GB.UTF-8' \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen && locale-gen &&
apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
docker-upgrade'
exit
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
chown -R 101:104 /var/discourse/shared/standalone/postgres_data
su - discourse
cd /var/discourse
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data
./launcher rebuild app
I needed to remove the local changes that had been made in the past for the PostgreSQL LANG using git stash; git stash drop and the moving of the PostgreSQL data directories needed to be be done as root and a chown was needed.
Is git pull required this time? Usually it isn’t.
It is never needed nowadays, becuse rebuild does it.
The trailing message Device or resource busy from the first error implies something else is holding a lock of that postgres_data directory so it cannot be moved.
Since that’s the database directory, one likely explanation is that postgres_data could be a mount point. This is even more likely since we see inter-device move failed in the second mv command, implying shared/postgres_data_new and shared/postgres_data are on different disks/partitions.
If you confirm that postgres_data is a mount point, you’ll have to manually move all files out of postgres_data into some other backup directory, and then move all the files from inside postgres_data_new into the (now empty) postgres_data directory. Both moves should be done after the first rebuild completes with UPGRADE OF POSTGRES COMPLETE but before issuing the second one.
If postgres_data is not a mount point, lsof is your friend. You can use that to try identify what’s causing the lock.
Of course, take necessary backups first.
This is perfect, thank you.
The files were in the following folder:
/var/postgres_data_discourse as postgres_data_new
The following fixed it.
I moved the postgres_data_new to /var
Renamed the postgres_data_discourse to postgres_data_discourse_old
Renamed the postgres_data_new to postgres_data_discourse
Issued ./launcher rebuild app
Thanks again 
I have 62g db, what do you suggest to perform the best upgrade?
62G /var/discourse/shared/standalone/postgres_data
I recommend that you move to a new VM, spin up a new Discourse, with an empty database (copying over the ssl and letsencrypt directories if you’d like a zero-downtime switch) and restore the current database to the new server. This allows you do to the upgrade with zero downtime and zero risk that something can go wrong.
It’s probably not too soon to upgrade your OS anyway.
If you’re asking if you can restore whatever old version of Discourse you have to whatever new version of Discourse you might get, the answer is yes.