その通りですが、私たちはシンプルで透過的なアップグレードメカニズムを目指しています。どちらにも利点があります。
自分のやりやすい方法で進めて、必要に応じて discourse_docker のテンプレートをカスタマイズすることを恐れないでください。もちろん、まずはテストを行い、ロールバック計画を立てることが重要です。
ホスティングプラットフォームでは、これを有効にする前にさらにテストとベンチマークを行う予定ですので、設定を揃えるために discourse_docker でも無効化しました。ただし、無効化することは必須ではありません（内部では discourse_docker の Web コンテナ部分のみを使用していますし）、有効化することにも反対しません。
一つ注意点として、pg_upgrade は、新旧のデータディレクトリのチェックサム設定が異なる場合、動作しません。手順としては、PG15 サーバーを停止し、pg_upgrade を実行してチェックサムなしで PG18 に変換し、pg_checksums を実行してチェックサムを有効化し、その後 PG18 を起動する必要があります。これはダンプとリストア（今回のアップグレードのような場合）を行う際には問題になりませんが、注意すべき点です。
データチェックサムは Postgres 9.3 から利用可能でしたが、これまでデフォルトでは無効でした。Postgres 19 では、オンラインで有効/無効を切り替える機能も追加されます。
[quote=“elmuerte, post:25, topic:406194, full:true”]
確認ですが、私は Discourse が提供する PostgreSQL を使用しておらず、Discourse 自体はまだ PG18 を必要としていない、ということですね？ つまり、私は（まだ）PG18 にアップグレードする必要はない、ということでしょうか。
[/quote]\n
現時点ではその通りです。Discourse の機能の大半は Rails の PostgreSQL アダプターを使用してデータベースと通信しますが、バックアップ/リストアには Web コンテナ内の pg_dump と psql を使用します。現在、これらのバージョンの両方を使用したバックアップ/リストアを有効にするために PG15 と PG18 のクライアントの両方をインストールしていますが、将来的には PG15 を削除する予定です。
主な要因は、新しい組み込みのロケールプロバイダーへの切り替えでした。ホスティングプラットフォームで OS のアップグレードを進めており、glibc への依存関係を解消したいと考えています。