どこかでPostgresのポートを5432ではなく50432に変更しましたか？（または、移行コードがそうしていて、私が気づかなかっただけかもしれません）。
OPで提案されているようにpostgres13テンプレートに切り替えてみてはどうでしょうか？そして、それがうまくいけば、新しいサーバーに移行して、Postgresのバージョン移行の問題全体を回避し、新しいサーバーにデータベースを復元するだけです。
「いいね！」 2
変更していませんし、そのソケットは存在するので… 
とりあえずそうしましたが、長期的には悪い考えだと思います。
サーバーを管理している人に伝えます。
「いいね！」 2
では、移動のために2つのPostgresを実行しているのかもしれません。
本当ですが、あなたが戻ってきてくれて安心しました！
「いいね！」 1
Discourseのパーティションでこのアップグレードを実行するのに十分なスペースがありません。しかし、別のドライブには十分なスペースがあります。これを一時ストレージとして使用する方法はありますか？
「いいね！」 1
いずれにせよOSのアップグレードの時期だろうし、新しいVMに移行する方がはるかに簡単で、ダウンタイムも少なく、何か問題が起きても、動作するサーバーが残ります。
別のデータコンテナがある場合は、/var/discourse/shared/dataをすべて別のパーティションに移動し、それに応じてYMLのボリュームを調整してみてください。
そして、別のコンテナがない場合は、そのようなことをすることもできますが、より複雑になります。
「いいね！」 2
同様の問題があります。ログを確認しましたか？
私の場合は、更新中に、カスタムプラグインとしてrss-pollingを追加したため、アプリ（私の場合はWebのみ）コンテナが再構築されないという問題が発生しました。これは新しいデフォルトと競合しているようです。それを削除すると機能しました。
しかし、その後、ベクトル拡張機能が見つからないという問題が発生しました。これは、しばらくデータコンテナを再構築していなかったためです。13に再構築できましたが、13が実行されている状態で、data.yamlをpostgres.templateまたはpostgres.15.templateに変更すると、マイグレーションが失敗します。
最初に「クリーンでないシャットダウン」で失敗しましたが、上記のヒントで解決できました。しかし、今度は13のインストールが見つからないように見えるため、マイグレーションが失敗しますか？これは/sharedディレクトリの残骸に関連している可能性がありますか？（postgres_newディレクトリのクリーンアップはすでに試しました）。
-----------------------------------------------------------------
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.
おそらく、古いコンテナ（それがわかれば）にPG13で戻してから、バックアップを作成し、新しいサーバーに移動します（おそらくOSも新しくする必要があるでしょう）。
お使いのコンテナは壊れた状態になっているようです。PG13テンプレートで再構築しようとしていますか？ postgresのバックアップフォルダをpostgres_dataに移動し、13に戻す必要があるかもしれません。
はい、現在PG13コンテナで実行しています。複数回再構築しました。また、不要な_newディレクトリもクリーンアップしました。しかし、15または公式のバージョンなしテンプレートに移動しようとするたびに失敗します。これは自己解決しない場合、すぐに手動で移行します。OSがここで関連しているとは思いません。
ボリュームマウントを再構築して、Shared または shared/postgres ディレクトリ全体を同じボリュームに配置することをお勧めします。そうすれば、ディレクトリ名の変更（定期的に必要になります）は問題にならなくなります。
それが直接的な問題に関連していない可能性もあります。しかし、Discourseを長期間実行していてPostgreSQLのアップグレードが必要になった場合、OSのアップグレードも必要になる可能性が高いです。
新しいサーバーに移行することで、実質的にダウンタイムなしで移行でき、壊れた状態になるリスクもありません。
一方で、私のスクリプト（ここで説明されていることだけを実行します）で実行したアップグレードのほとんどは問題なく完了しました。
バージョン番号が付いていない方（unversioned）に切り替えてから、2回の再構築を行うのが良いと思います。
試しましたが、どちらも機能しません。手動で行います。