注意：理由には確信が持てませんが、PostgreSQL 18 へのアップグレードではネイティブなデータチェックサムが無効化されます。PostgreSQL のデータチェックサムはデフォルトで有効な機能であり、これを無効にするのは非常に不自然です。
データチェックサムを無効にしないためのPR（デフォルトで有効）: Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
1年に1回、1時間だけ必要になるために20GBの空き容量を確保しておかなければならないよりマシだよ、笑
もしかしたら、木や水を節約するためにはこれが推奨される方法になるべきかもしれないね。
確認ですが、私はDiscourseが提供するPostgreSQLを使用していませんし、Discourse自体はまだPG18を必要としていませんよね？ つまり、私は（まだ）PG18へのアップグレードは必要ありません。
その通りですね。ただし、もう一つの理由は、LTS（長期サポート）リリースは数年に一度しか行われないため、そのタイミングでまとめて行うのは悪くないアイデアだということです。
確かにまだ時間があります。ある特定の機能が必須だったため、アップデート直後にかなり速くあるリリースを推奨しましたが、おそらく1年ほど待っても問題ないでしょう。私はdiscourse_dockerリポジトリをウォッチしています。いずれPG15のサポートを削除する話が出始めますが、特に騒がしい話題ではなく、内部の更新状況を把握する簡単な方法です。
「いいね！」 2
私のPi 5のインストールでは問題なく動作し、2回の再構築で完了しました。
「いいね！」 7
ちなみに、ベンチマークはありますか？
あれば、他の人も私たちの勇敢な足跡を早く追ってくださるかもしれません。
私の無料のWeb検索AIによると、以下のようです：
典型的なRailsアプリの場合、PostgreSQL 15から18への移行により、コードを変更せずに約10～25%のクエリパフォーマンス向上が期待できます。また、新しいインデックス機能やプランナーの機能を活用すれば、特定のクエリパターンでは**最大40%**の向上も見込めます。
もしこれが本当なら、かなり大きなアップグレードですね！ 
「いいね！」 7
当社のセルフホスト型インスタンスで、すべてが問題なく完了したことを確認しました。このアップデートありがとうございます。今後の状況も随時お知らせください。
「いいね！」 5
その通りですが、私たちはシンプルで透過的なアップグレードメカニズムを目指しています。どちらにも利点があります。
自分のやりやすい方法で進めて、必要に応じて 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 への依存関係を解消したいと考えています。
「いいね！」 3
PostgreSQL はコンテナとは独立して自分で管理しています。pg18 に切り替えるために推奨される Git ハッシュはどれですか？
「いいね！」 1
e7f1201 で、バックアップ互換性のために web イメージに PG18 クライアントが追加されました。discourse_docker の Postgres サーバーコンポーネントを一切使用していない場合、PG18 にはこのリビジョン以降を使用する必要があります。
「いいね！」 1
私が話していたのは、1回か2回前のアップグレードのことです。
[quote=“chrisr, post:30, topic:406194”]
その通りですが、私たちはシンプルで透過的なアップグレードメカニズムを目指しています。どちらにもメリットがあります。
[/quote]\n
その通りです。私の言いたかったのは、新しいバージョンに古い PostgreSQL のバックアップを復元できることにも同等のサポートが必要だということです。インプレースアップグレードのメカニズムは、大多数の人にとって非常にうまく機能していますが、何か問題が発生した場合、どう対処すればよいか分かりにくいです（主に、それがめったに起こらないためです）。
「いいね！」 2
もし誰かの助けになればいいのですが、SSH コンソールが止まったままの瞬間や、冷や汗が吹き出すパニックが込み上げてくるような瞬間には…
私は別のターミナルでこれを実行して、進捗状況を見守っていました：
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'これは10秒ごとに更新され、冷静さを保つのに役立ちます
私の35GBの移行には、約10分かかりました。
「いいね！」 8
私のところでは、標準インストールでアップデートが問題なく完了しました。もちろん、何かトラブルに備えて事前にバックアップを作成してダウンロードしておきました 
「いいね！」 3
いいね。それに free -h を追加するべきだ - メモリ不足はよくある問題だからだ。
watch や top の唯一の問題は、画面が絶えず更新されるため、何かを見落としてしまう可能性があることだ。リソースが枯渇して更新が失敗した場合、数秒後には記録が失われてしまう。そのため、私はより while ループのようなものを実行する傾向がある。例えば以下のようなものだ：
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
「いいね！」 4
成功事例を報告します．．．マルチサイト設定の半分についてです。デフォルトのサイトは期待通りに移行しましたが、セカンダリサイトは新規インストールされたように見えました。幸い、バックアップからの復元は容易です。クライアント用に使用している別のサーバーがあり、新しいDropletを立ち上げてバックアップからサイトを復元してこのアップデートを行うことを検討しています。これは非標準的なインストールを使用するリスクの一つだと思います。
「いいね！」 1
データコンテナは標準的なデータコンテナでしたか？クラスタ内のデータベースを1つだけ移動するのか、それともすべて移動するのか気になっていました。質問に答えてくださったようですね！
私がこれまでにやっていたのは、各データベースを旧クラスタから新クラスタへ手動で移動し、その後 discourse.conf を手動で編集して新しいデータベースを指定し、さらにビルドを再実行してマルチサイトコンテナ全体を新しいクラスタ（別のマシンまたはポート上）に向けるという方法です。
「いいね！」 1
ええ、そうです。もちろん、私のセットアップで何かミスをしていないとは言い切れません。
postgres データを rsync して、そこで qn アップグレードを実行し、プロセスが discourse データベースのみを移動するのか、それともクラスタ全体を移動するのかを確実に確認する計画を立てていました。しかし、あなたが私の質問に答えてくれたようですし、コードを見れば明らかになるでしょう。
「いいね！」 2
2つの質問があります：
- テストサーバーに追加のストレージブロックをマウントしました。しかし、PostgreSQLのアップグレードは、スペースチェックがメインディスクのみをチェックしているため失敗します。スペースチェックを回避する方法はありますか？
- 本番サイトではGoogle Cloud SQLを使用しています。Google Cloud経由でアップグレードする前に知っておくべきことはありますか？