PostgreSQL 18 比較：AppStreamとPGDGの導入設計



AlmaLinuxやRHEL系のLinuxサーバーにPostgreSQLを導入する際、最初に直面する重要な分岐点が「どのリポジトリからインストールするか」という選択です。OS標準のAppStreamリポジトリと、PostgreSQLコミュニティ公式のPGDGリポジトリでは、配置されるディレクトリ構造やサービス管理コマンド、さらには将来のメジャーバージョンアップ時の難易度が根本から異なります。

1. なぜ2種類のリポジトリが存在するのか：設計思想の違い#

1.1 AppStream版（OS標準提供）のメリットと制約#

AlmaLinux（およびRed Hat Enterprise Linux）の標準リポジトリであるAppStreamから提供されるPostgreSQLパッケージは、OS自体の安定稼働とライフサイクル統合を最優先に設計されています。

AppStream版を採用する場合の主な特徴は以下の通りです。

• OSライフサイクルとの同期：パッケージの更新やセキュリティパッチの提供がOSディストリビューションの方針に従って管理されます。OS全体の定期メンテナンス（dnf update）を実行するだけで、PostgreSQLのマイナーアップデートも一括で適用されます。
• 追加リポジトリ不要：外部リポジトリの登録やGPG鍵のインポートが不要であるため、セキュリティ規定が厳しい閉域網環境でも導入ハードルが低い利点があります。
• 単一パスへの固定：バイナリは/usr/bin/postgres、データディレクトリは/var/lib/pgsql/dataという標準パスに配置されます。この設計はシンプルである反面、「同一OS上に複数の異なるメジャーバージョンを共存させること」ができません。

1.2 PGDG公式RPM版（コミュニティ公式提供）のメリットと制約#

一方、PostgreSQLの開発元であるPostgreSQL Global Development Group (PGDG)が直接ビルドして配布している公式RPMリポジトリは、データベース専任の運用や長期的なバージョン管理を前提に設計されています。

PGDG版を採用する場合の主な特徴は以下の通りです。

• スロット化されたパス設計：実行バイナリは/usr/pgsql-XX/bin/、データ領域は/var/lib/pgsql/XX/data/のように、メジャーバージョン番号（XX）を含む専用ディレクトリ配下に分離して格納されます。
• 新旧バージョンの並行インストール：パスが完全に分離されているため、1台のサーバー上にPostgreSQL 16とPostgreSQL 18を同時にインストールして共存させることが可能です。この特徴は、後述するpg_upgradeを用いたメジャーバージョンアップにおいて決定的な利点となります。
• 最新リリースの即時利用：コミュニティで新しいメジャーバージョンや緊急セキュリティパッチが公開された際、OSベンダの検証を待つことなく即日パッケージを入手できます。

2. AppStream vs PGDG 構造比較一覧#

実務で頻繁に使用する主要パス、初期化コマンド、サービス名の違いを一覧表で整理します。

2.1 systemdユニット定義ファイルの内部構造比較#

サービスを管理するsystemdのユニット定義（.serviceファイル）にも、両方式の思想の差異が反映されています。それぞれの配置パスおよび主要ディレクティブを確認します。

[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=notify
User=postgres
Group=postgres
Environment=PGDATA=/var/lib/pgsql/data
ExecStart=/usr/bin/postgres -D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target

[Unit]
Description=PostgreSQL 18 database server
Documentation=https://www.postgresql.org/docs/18/static/
After=network.target

[Service]
Type=notify
User=postgres
Group=postgres
Environment=PGDATA=/var/lib/pgsql/18/data/
Environment=PGENGINE=/usr/pgsql-18/bin
ExecStart=/usr/pgsql-18/bin/postgres -D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=300

[Install]
WantedBy=multi-user.target

2.2 コマンドラインツールのパス解決とフルパス指定の運用原則#

管理者が端末からpsqlやpg_dumpを実行する際のパス解決方法にも大きな違いがあります。

• AppStream版：コマンド類が標準の/usr/bin/に配置されるため、環境変数を設定しなくても全ユーザーが即座にpsqlコマンドを呼び出せます。
• PGDG版：/usr/pgsql-18/bin/配下にバージョンごとに完全分離して格納されます。複数バージョンのバイナリ衝突を防ぐため、デフォルトでは/usr/bin/への自動登録は行われません。

3. 【実践】AppStream版のインストールと初期構築（alma-db02）#

実機ノードalma-db02を使用して、OS標準のAppStreamリポジトリからPostgreSQLを導入し、データベースクラスタの初期化からサービス起動までの手順を確認します。

3.1 パッケージの確認とインストール#

まず、AppStreamリポジトリで提供されているPostgreSQL関連パッケージを確認し、サーバー本体をインストールします。

$ sudo dnf install -y postgresql-server
依存関係が解決しました。
================================================================================
 パッケージ                  Arch       バージョン          リポジトリー  サイズ
================================================================================
インストール:
 postgresql-server           x86_64     16.14-1.el10_2      appstream     6.9 M
依存関係のインストール:
 libicu                      x86_64     74.2-5.el10_0       baseos         10 M
 postgresql                  x86_64     16.14-1.el10_2      appstream     1.9 M
 postgresql-private-libs     x86_64     16.14-1.el10_2      appstream     143 k

完了しました!

AlmaLinux 10環境では、PostgreSQL 16.14のパッケージが依存関係（クライアント、共有ライブラリ等）とともに自動解決されて導入されます。

3.2 データベース初期化とsystemdサービス起動#

インストール直後の状態では、データベースクラスタ（実体ファイル群）が未作成のため、初期化スクリプトを実行します。

# クラスタの初期化
$ sudo postgresql-setup --initdb
 * Initializing database in '/var/lib/pgsql/data'
 * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

# サービスの有効化（自動起動登録）と即時起動
$ sudo systemctl enable --now postgresql
Created symlink '/etc/systemd/system/multi-user.target.wants/postgresql.service' → '/usr/lib/systemd/system/postgresql.service'.

# 稼働状態とバージョンの確認
$ systemctl is-active postgresql
active

$ sudo -u postgres psql -c "SELECT version();"
                                                    version                                                    
---------------------------------------------------------------------------------------------------------------
 PostgreSQL 16.14 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit

実行後、/var/lib/pgsql/data配下にクラスタ構造が生成され、postgresql.serviceが正常に起動していることが確認できます。

4. 【実践】PGDG公式RPM版のインストールと初期構築（alma-db01）#

次に、実機ノードalma-db01を使用して、PostgreSQLコミュニティ公式のPGDGリポジトリを登録し、最新のPostgreSQL 18を導入する手順を確認します。

4.1 PGDGリポジトリRPMの導入とEL-10での注意点#

PGDG版を利用するには、まずコミュニティが配布しているリポジトリ定義RPMをインストールします。

# EL-10用 PGDGリポジトリRPMのインストール
$ sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-10-x86_64/pgdg-redhat-repo-latest.noarch.rpm
インストール済み:
  pgdg-redhat-repo-42.0-66.rhel10PGDG.noarch

完了しました!

4.2 指定バージョンのインストール・初期化・サービス起動#

PGDGリポジトリから、利用したいメジャーバージョンのサーバーパッケージを指定してインストールします。ここではPostgreSQL 18を選択します。

# PostgreSQL 18 サーバーパッケージのインストール
$ sudo dnf install -y postgresql18-server
インストール済み:
  libicu-74.2-5.el10_0.x86_64                                                   
  liburing-2.12-1.el10.x86_64                                                   
  postgresql18-18.6-4PGDG.rhel10.2.x86_64                                       
  postgresql18-libs-18.6-4PGDG.rhel10.2.x86_64                                  
  postgresql18-server-18.6-4PGDG.rhel10.2.x86_64                               

完了しました!

PGDG版の初期化スクリプトおよびsystemdサービス名には、必ずメジャーバージョン番号が含まれる点に注意してください。

# バージョン別初期化スクリプトの実行
$ sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
Initializing database ... OK

# サービス有効化と起動（サービス名は postgresql-18）
$ sudo systemctl enable --now postgresql-18
Created symlink '/etc/systemd/system/multi-user.target.wants/postgresql-18.service' → '/usr/lib/systemd/system/postgresql-18.service'.

# 稼働状態とバージョンの確認
$ systemctl is-active postgresql-18
active

$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SELECT version();"
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 18.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit

データディレクトリは/var/lib/pgsql/18/dataに生成され、バイナリも/usr/pgsql-18/bin/配下に格納されていることが実機で確認できます。

4.3 initdb 詳細オプション設計：データチェックサムとICUロケール#

パッケージ付属のセットアップスクリプト（postgresql-18-setup initdb等）は標準的なデフォルト値で初期化を行いますが、エンタープライズの本番システムを設計する際には、initdbコマンドを直接実行するか、環境変数を指定して重要なクラスタオプションを明示的に指定することが推奨されます。

# 本番推奨オプションを指定した手動初期化コマンド例
$ sudo -u postgres /usr/pgsql-18/bin/initdb \
    -D /var/lib/pgsql/18/data \
    --encoding=UTF8 \
    --locale-provider=icu \
    --icu-locale=ja-JP \
    --data-checksums

# クラスタ状態およびデータチェックサムの有効性確認（pg_controldata）
$ sudo -u postgres /usr/pgsql-18/bin/pg_controldata -D /var/lib/pgsql/18/data | grep "Data page checksum"
Data page checksum version:           1

# ロケールプロバイダ（ICU / ja-JP）の確認（psql）
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SELECT datname, datlocprovider, datlocale FROM pg_database WHERE datname = 'postgres';"
 datname  | datlocprovider | datlocale 
----------+----------------+-----------
 postgres | i              | ja-JP
(1 行)

4.4 実機検証：同一ホスト内での複数メジャーバージョン並行稼働#

PGDG公式RPM版の大きな強みの一つは、将来のメジャーバージョンアップ移行期において、同一OS上で新旧バージョンを競合させずに安全に並行稼働できる点にあります。ここでは、本シリーズ第8回（pg_upgrade移行実務）の事前検証シナリオを想定し、既存の旧環境（PostgreSQL 17がポート5432で稼働中）が存在するサーバーに対して、新環境（PostgreSQL 18）を追加導入し、ポートを5433に変更して同時に稼働させる共存検証の手順と仕組みを確認します。

# 1. 2つのバージョンの稼働状態を確認
$ systemctl is-active postgresql-17 postgresql-18
active
active

# 2. リスニングポートの確認（5432と5433が並行して待ち受け）
$ sudo ss -tulpn | grep postgres
tcp   LISTEN 0      244    0.0.0.0:5432   0.0.0.0:*   users:(("postgres",pid=1201,fd=7))
tcp   LISTEN 0      244    0.0.0.0:5433   0.0.0.0:*   users:(("postgres",pid=8540,fd=7))

# 3. プロセスツリーの確認（別々のバイナリパスから起動）
$ ps aux | grep [p]ostgres | grep -E "/usr/pgsql-(17|18)" | awk '{print $1, $2, $11}'
postgres 1201 /usr/pgsql-17/bin/postgres
postgres 8540 /usr/pgsql-18/bin/postgres

# 4. 各ポートへの接続テスト
$ /usr/pgsql-17/bin/psql -p 5432 -U postgres -c "SELECT version();" | head -n 3
                                                  version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 17.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit

$ /usr/pgsql-18/bin/psql -p 5433 -U postgres -c "SELECT version();" | head -n 3
                                                  version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 18.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), 64-bit

このように、バイナリ・ライブラリ・データ配置が完全に独立しているため、ポート番号を分けるだけで同一OS上で安全に並行稼働できます。この仕組みこそが、第8回で解説する「ダウンタイム数秒のメジャーバージョンアップ（pg_upgrade）」を可能にする物理的基盤です。

5. 実務トラブルシューティング事例集（3大障害シナリオと解決策）#

PostgreSQLのインストールや初期クラスタセットアップ時に頻発する代表的な障害シナリオ3選と、その原因および解決策を整理します。

5.1 シナリオ1：PGDGリポジトリ追加時のGPG署名検証エラー・接続タイムアウト#

社内ネットワークや閉域網環境からdnf installを実行した際、PGDGリポジトリのメタデータ取得やRPMパッケージのGPG鍵検証に失敗し、インストールが中断する障害です。

$ sudo dnf install -y postgresql18-server
PostgreSQL 18 for RHEL / Rocky / AlmaLinux 10 - x86_64   12 kB/s | 3.1 kB     00:00    
GPG 公開鍵のダウンロード中: https://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG
エラー: GPG 署名の検証に失敗しました: [Errno 14] Curl error (28): Timeout was reached for https://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG

原因：プロキシサーバー経由の通信環境において、dnfにプロキシ設定が未定義である場合や、社内ファイアウォールによってdownload.postgresql.orgへの443ポート通信が遮断されていることが原因です。

5.2 シナリオ2：AppStream版とPGDG版の混在によるパッケージ競合（transaction check error）#

すでにAppStream版のPostgreSQL関連ライブラリ（例: postgresql-libs）が導入されている環境に対してPGDG公式RPM版をインストールしようとした際、依存ライブラリのバージョンやファイル衝突によりインストールが失敗する事象です。

エラー: トランザクションの確認エラー:
  file /usr/lib64/libpq.so.5 from install of libpq5-18.6-4PGDG.rhel10.x86_64 conflicts with file from package postgresql-libs-16.14-1.el10.x86_64

原因：OS標準のAppStream版クライアント共有ライブラリ（libpq）と、PGDG版が提供するlibpq5が、同一のファイルパス（/usr/lib64/libpq.so.5）を巡って競合するために発生します。

解決策：構築初期段階であれば、OS標準のパッケージを完全に除去した上でPGDG版を導入します。

# 1. 競合しているOS標準パッケージのアンインストール
$ sudo dnf remove -y postgresql postgresql-server postgresql-libs

# 2. PGDG公式パッケージを新規導入
$ sudo dnf install -y postgresql18-server

5.3 シナリオ3：OS更新に伴うglibc照合順序変更とインデックス不整合警告#

OSの定期パッチ適用（dnf update glibc）を実施した後、PostgreSQLのログに照合順序（Collation）のバージョン不整合警告が出力され、検索結果の順序狂いや重複制約違反見逃しが発生する重大トラブルです。

WARNING:  database "production_db" has a collation version mismatch
DETAIL:  The database was created using collation version 2.34, but the operating system provides 2.39.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE production_db REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

原因：データベース作成時にOSのglibcロケール（例: ja_JP.UTF-8）を使用している場合、glibcのバージョンアップによって文字列の比較ソート順が変更されると、既存のB-treeインデックスが正しく走査できなくなります。

6. 初期導入直後の必須セキュリティ・環境設定チェックリスト#

PostgreSQLパッケージのインストールとクラスタ初期化を完了した直後に、インフラ運用担当者が必ず確認・設定すべき初期セキュリティ項目を整理します。

6.1 データディレクトリのパーミッションとSELinuxコンテキスト#

PostgreSQLのデータディレクトリ（/var/lib/pgsql/XX/data）は、機密データおよび認証情報を保護するため、所有者以外の全アクセスが遮断されていなければサービスが起動しません。

# パーミッションの確認（必ず 0700 / drwx------ であること）
$ ls -ld /var/lib/pgsql/18/data
drwx------. 19 postgres postgres 4096  9月  9 20:00 /var/lib/pgsql/18/data

# SELinuxコンテキストの確認（postgresql_db_t であること）
$ ls -Zd /var/lib/pgsql/18/data
system_u:object_r:postgresql_db_t:s0 /var/lib/pgsql/18/data

ストレージ増設などでデータディレクトリを別パーティション（例: /data/pgdata）に移動した場合、パーミッションが0700かつ所有者がpostgres:postgresであることに加え、semanage fcontext -a -t postgresql_db_t "/data/pgdata(/.*)?"およびrestorecon -Rv /data/pgdataを実行してSELinuxコンテキストを正しく適用しないと、SELinuxによって起動が拒否されます。

6.2 クライアントツールのPATH環境変数の設定#

PGDG版を導入した場合、サーバー上の運用オペレータや保守スクリプトが即座にコマンドを実行できるよう、全ユーザー共通のプロファイル設定を作成します。

# /etc/profile.d/pgsql.sh の作成
$ sudo bash -c 'cat << "EOF" > /etc/profile.d/pgsql.sh
export PATH=/usr/pgsql-18/bin:$PATH
export MANPATH=/usr/pgsql-18/share/man:$MANPATH
EOF'

# 設定の即時反映と確認
$ source /etc/profile.d/pgsql.sh
$ which psql
/usr/pgsql-18/bin/psql

6.3 ログ出力設計と日次ローテーションの有効化#

障害発生時の迅速な調査のため、初期化直後にpostgresql.confのログ収集機能を有効化します。

7. どちらを選ぶべきか？実務での選定フローチャート#

要件や現場の制約に応じて、どちらのリポジトリを採用すべきかの判断基準をフローチャートで整理します。

判断基準の要点は以下の通りです。

1. 社内規定で外部リポジトリの登録が禁止されている場合：

   選択の余地なくAppStream版を採用します。OSの標準サポート契約の範囲内で運用を完結させたいエンタープライズ環境に適しています。

2. 将来のメジャーバージョンアップでサービス停止時間を最小化したい場合：

   PGDG公式RPM版の採用を推奨します。同一サーバー上に新旧バージョンを並行インストールできるため、後述のシリーズ第8回で解説するpg_upgrade --link（ハードリンク移行）を活用することで、数十ギガ〜数テラバイト規模のデータでも数分以内で移行を完了できます。

3. 最新機能や早期パッチ提供が必要な場合：

   コミュニティから最新機能が即座に供給されるPGDG公式RPM版を選択します。

8. 本番想定 総合確認演習問題#

実務でリポジトリや初期構築を扱う際に必須となる知識を確認演習問題で点検します。

9. まとめと次回予告#

次回は第3回「postgresql.conf と pg_hba.conf の基本設計とアクセス制御」を解説します。初期構築を終えた直後の安全な接続待ち受け設定（listen_addresses）、SCRAM-SHA-256によるセキュアなパスワード認証、および社内ネットワークからの安全な接続制限ルールを実機設定ファイルを用いて整理します。

リンク