So somewhere you changed the postgres port to 50432 instead of 5432? (OR maybe the migration code does that and I’ve never noticed).
Maybe switch to the postgres13 template as suggested in the OP? And if that works, what I would do is move to a new server and avoid the whole transition-to-new-postgres-version issue and just restore the database to the new server.
I didn’t change it, and that socket does exist so… 
I did that for now, but I assume that’s a bad idea long-term
I’ll let the one who manages the server know ig
So maybe it does run two postgres to make the move.
True, but I’m relieved that your back up!
I don’t have enough space to perform this upgrade on my Discourse partition. However, I have plenty of space on another drive. Is there a way to use this for the temporary storage?
It’s probably time for an OS upgrade anyway, and moving to a fresh VM is much easier, requires little downtime, and if something goes wrong, you still have a working server.
If you’ve got a separate data container, you can try moving all of /var/discourse/shared/data to the other partition and adjusting the volumes in your YML accordingly.
And if you don’t have a separate container, you can do something like that, it’s just more complicated.
I have a similoiar (same?) problem. Did you check the log mentions?
In my case: When I was updating I first got a problem that the app cpntainer wont rebuild because I had added rss-polling as a custom plugin and this seems to clash with the new defaults. After removing that it worked. But then it had problems with the missing vector extension. This was because I hadnt rebuild the data container in a while. I managed to do this to 13 now, but now I am stuck. With 13 running, when i change my data.yaml to postgres.template or postgres.15.template the migration fails.
First it failed with “unclean shutdown” and with the hints above I could resolve this. But now the migration fails, since it seems to be missing the 13 install? Mays this be related to some leftovers in the /shared directory? (I already tried to clean the postgres_new dir).
-----------------------------------------------------------------
pg_upgrade run on Fri Oct 17 09:54:37 2025
-----------------------------------------------------------------
command: "/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" -D "/shared/postgres_data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" 2>&1
waiting for server to start....2025-10-17 09:54:37.744 UTC [1900] LOG: starting PostgreSQL 13.22 (Debian 13.22-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-10-17 09:54:37.749 UTC [1900] LOG: listening on Unix socket "/var/lib/postgresql/.s.PGSQL.50432"
2025-10-17 09:54:37.760 UTC [1900] LOG: could not open configuration file "/etc/postgresql/13/main/pg_hba.conf": No such file or directory
2025-10-17 09:54:37.760 UTC [1900] FATAL: could not load pg_hba.conf
2025-10-17 09:54:37.762 UTC [1900] LOG: database system is shut down
stopped waiting
pg_ctl: could not start server
Examine the log output.
```
What I’d probably do is switch back to PG13 with the old container (if you can figure that out) then make a backup and move to a new server (you likely need a new OS anyway).
It looks like the container you’ve got is in some broken state. Is that trying to rebuild with the PG13 template? You might need to move the postgres backup folder to postgres_data and switch back to 13 to get things going again.
Yes I run currently with the PG13 Container. I have rebuild it multiple times. I even cleaned up the dangling _new Directory. Just every time I try to go to 15 or the official unversioned Template it fails. I will migrate it manually soon if this does not fix itself. I dont see how the OS is relevant here.
BTW the script sequence differs in postgres.15.template and postgres.template, which one is better for the Update?
I would restructure your volume Mount so that the whole Shared or shared/postgres Directory is on the Same volume, then the Renates (which are regularly needed) wont be an issue anymore.
It may not be related to the immediate issue. It’s often the case that if you’ve been running discourse long enough to need a postgres upgrade you likely are due for an os upgrade as well.
Moving to a new server allows you to move with virtually no downtime and no risk that you’ll end up in some broken state.
Otoh, most of the upgrades I ran with my script (that just does what’s described here) went off without a problem.
I think you’d switch to the unversioned one, then do the two rebuilds.