PostgreSQL 18 のマイナーバージョンアップ実務：安全な更新と切り戻し



データベースを本番運用する上で、セキュリティ脆弱性（CVE）への対処や予期せぬクラッシュを引き起こすバグの解消は避けて通れない重要責務です。PostgreSQLグローバル開発グループ（PGDG）からは、約3ヶ月に1回のペースで定期的な「マイナーアップデート」がリリースされます。しかし、「メジャーバージョンアップと何が違うのか」「どのような手順で安全に更新すべきか」「万一起動しなくなったときにどう切り戻すか」という実務基準が確立されていない現場は少なくありません。

マイナーバージョンアップは、データ移行作業が一切不要であり、実行ファイルの置換と再起動のみで完結する安全性の高い作業です。しかし、事前のバックアップを怠ったり、OS全体の自動アップデートによって予期せぬタイミングで更新されてしまうと、不要な障害を招きます。本稿では、マイナーバージョンの互換性の仕組み、AppStream版とPGDG版でのパッケージ管理の挙動差、安全な7ステップ作業標準、および万一のダウングレード切り戻し手順を整理します。

目次

1. 1. PostgreSQLのバージョニング規則とマイナー更新の本質
   1. 1.1 バージョン番号の読み方
   2. 1.2 なぜマイナーアップデートはデータ移行が不要なのか
   3. 1.3 計画停止枠（ダウンタイム）の短さ
2. 2. パッケージリポジトリ別の更新挙動：AppStream vs PGDG
   1. 2.1 AppStream版：OS標準アップデートに巻き込まれるリスク
   2. 2.2 PGDG版：バージョン明示的な安全更新設計
   3. 2.3 リリースノート確認の重要ポイント
   4. 2.4 レプリケーション環境におけるマイナーバージョン混在互換性
   5. 2.5 マイナーアップデートで修正される主要な不具合類型
3. 3. 実務標準：マイナーバージョンアップの7ステップ作業手順
   1. 3.1 接続セッションの安全なドレイン（Drain）と切断フロー
   2. 3.2 計画停止時のメンテナンス画面ルーティング設計
4. 4. 【実機検証】AlmaLinux 10でのアップデート実践と切り戻しテスト
   1. 4.1 アップデート前の初期状態確認
   2. 4.2 計画停止から dnf update によるバージョンアップ実行
   3. 4.3 起動後のバージョン確認と既存データの完全保全確認
   4. 4.4 万一の不具合発生時：dnf downgrade による切り戻し検証
   5. 4.5 切り戻しにおけるデータ整合性の注意点
   6. 4.6 リリースノート特定指示に基づく REINDEX 実機検証
5. 5. 実務チートシート：意図せぬ自動更新を防ぐ versionlock 設定
6. 6. 実務トラブルシューティング事例集（3大障害シナリオと解決策）
   1. 6.1 事例1：dnf update 実行時のパッケージ依存関係エラー
   2. 6.2 事例2：拡張モジュール（Extension）の関数ロードエラー
   3. 6.3 事例3：ダウングレード切り戻しにおける後退リスクと安全原則
   4. 6.4 事例4：pg_stat_statements 実行統計リセットの運用判断
7. 7. 実務チートシート：マイナーバージョンアップ計画・点検チェックリスト
   1. 7.1 実務作業手順書の標準タイムテーブル設計例
8. 8. 理解度確認演習問題（全3問・解答解説付き）
9. 9. まとめと次回予告

1. PostgreSQLのバージョニング規則とマイナー更新の本質#

1.1 バージョン番号の読み方#

PostgreSQLのバージョン番号は、バージョン10以降、「メジャー.マイナー」という2桁のシンプルな体系に統一されています。

• メジャーバージョン（第1数値）：16、17、18 などの数値を指します。年に1回（通常秋頃）リリースされ、新機能の追加、内部アーキテクチャの刷新、パフォーマンスの向上、および後方互換性の変更が含まれます。
• マイナーバージョン（第2数値）：18.1、18.4、18.6 などの末尾の数値を指します。数ヶ月ごとにリリースされ、セキュリティ脆弱性の修正や深刻な不具合のバグ修正のみが含まれます。新機能の追加は原則として行われません。

1.2 なぜマイナーアップデートはデータ移行が不要なのか#

メジャーバージョンアップ（第8回で後述）では、データディレクトリ（$PGDATA）の内部構造やシステムカタログ定義、データ型OIDの配置が変更されるため、古いクラスタのデータファイルを新バージョンのバイナリで直接読み込むことはできません。そのため、pg_upgradeコマンドやダンプ/リストアによる大掛かりなデータ移行が必要となります。

対照的に、同一メジャー系列内におけるマイナーアップデート（例: 18.4 から 18.6）では、ディスク上のデータブロック形式（内部レイアウト）が100%完全同一に保たれることが公式に保証されています。データベースエンジンを停止させ、実行ファイル（バイナリ）を新しいバージョンに置き換えて再起動するだけで、既存のデータディレクトリをそのまま何事もなかったかのように読み込んで処理を継続できます。

1.3 計画停止枠（ダウンタイム）の短さ#

データ変換のオーバーヘッドが一切発生しないため、シングル構成におけるマイナーアップデートの所要時間は「サービスの停止 ＋ パッケージの置換 ＋ サービスの起動」に要する時間のみです。一般的な環境であれば、わずか1〜2分程度の計画停止枠で作業を完了できます。

2. パッケージリポジトリ別の更新挙動：AppStream vs PGDG#

第2回で解説したリポジトリの選定方針は、バージョンアップ作業の運用性にも直接影響を与えます。

2.1 AppStream版：OS標準アップデートに巻き込まれるリスク#

AlmaLinuxのOS標準リポジトリ（AppStream）から導入した場合、パッケージ名はpostgresql-serverという汎用的な名称になります。

# AppStream版のアップデート
$ sudo dnf update postgresql-server

注意すべきリスクは、インフラ管理者がOSの定期セキュリティパッチ適用としてsudo dnf updateを全体実行した際、PostgreSQLのパッケージも自動的に巻き込まれて更新されてしまう点です。意図しないタイミングでデータベースが再起動されたり、仕様変更が適用されるのを防ぐため、本番環境では更新対象から除外する運用（versionlock）が推奨されます。

2.2 PGDG版：バージョン明示的な安全更新設計#

PostgreSQL公式コミュニティが提供するPGDGリポジトリでは、メジャーバージョンごとにパッケージ名が完全に分離されています（例: postgresql18-server）。

# PGDG版のアップデート（18系マイナーのみが対象）
$ sudo dnf update postgresql18-server

この設計により、意図せずメジャーバージョンが上がってしまう危険性が構造的に排除されています。また、リポジトリ内には過去のマイナーバージョン（18.0, 18.1, 18.4等）のRPMパッケージもアーカイブとして保持されているため、特定バージョンへの固定やダウングレードを柔軟に行えます。

2.3 リリースノート確認の重要ポイント#

マイナーアップデートは互換性が重視されているとはいえ、適用前には必ず公式リリースノート（Release Notes）を確認し、変更内容を確実に把握してください。特に注意すべき項目は以下の2点です。

• CVE識別番号と重要度：自社環境が抱える脆弱性の深刻度（CVSSスコア）を評価し、緊急適用すべきか定期保守で対応すべきかを判断します。
• REINDEX指示の有無：稀に「B-Treeインデックスの破損につながるバグ修正」が含まれる場合があり、その際はリリースノートに「バージョンアップ後にREINDEX TABLEまたはREINDEX DATABASEを実行してください」という特記事項が明記されます。この指示を見落とすと、インデックス不整合による検索漏れを引き起こす恐れがあります。

2.4 レプリケーション環境におけるマイナーバージョン混在互換性#

将来的なクラスタ冗長化（第09回参照）を見据えた場合、マイナーバージョンアップにおけるレプリケーション互換性ルールを正しく理解しておく必要があります。

PostgreSQLの公式仕様では、同一メジャーバージョン内であれば、異なるマイナーバージョンのノード間での物理ストリーミングレプリケーションが完全保証されています（例：Primaryが18.4でStandbyが18.6、あるいはその逆）。

2.5 マイナーアップデートで修正される主要な不具合類型#

「システムが安定稼働しているなら、あえてマイナーバージョンアップを行う必要はないのではないか」という疑問を持つエンジニアも少なくありません。しかし、PostgreSQLコミュニティが3ヶ月ごとにリリースするマイナーバージョンには、以下のような実務上無視できない重大な修正が含まれています。

3. 実務標準：マイナーバージョンアップの7ステップ作業手順#

シングル構成のデータベースにおいて、人為的ミスや予期せぬトラブルを完全に防ぐための標準作業ワークフローを提示します。

3.1 接続セッションの安全なドレイン（Drain）と切断フロー#

データベースサービスを停止（systemctl stop）する際、最も回避すべき事態は「更新トランザクションを実行中のセッションが強制中断され、未コミット処理がロールバックされる」ことです。安全にサービスを停止させるため、以下の事前ドレイン手順を実施します。

-- 1. 新規接続の受付を一時遮断（一般ユーザーの接続不可）
ALTER DATABASE production_db CONNECTION LIMIT 0;

-- 2. 現在実行中のアクティブセッション数を確認
SELECT count(*) FROM pg_stat_activity WHERE datname = 'production_db' AND pid <> pg_backend_pid();

-- 3. 残存しているセッションを安全に強制切断（管理者セッション以外）
SELECT pg_terminate_backend(pid) 
FROM pg_stat_activity 
WHERE datname = 'production_db' AND pid <> pg_backend_pid();

接続が完全にゼロになったことを確認した上で systemctl stop を発行することで、クリーンなチェックポイントがディスクに書き込まれ、数秒での安全なプロセス停止が可能になります。

3.2 計画停止時のメンテナンス画面ルーティング設計#

WebサービスやAPIを伴う本番システムでは、データベース停止中にエンドユーザーへ「DB接続エラー（HTTP 500）」画面が露出することは避けなければなりません。リバースプロキシ（Nginx / ALB）と連携し、計画停止中は「システムメンテナンス中（HTTP 503）」画面へ自動ルーティングする設計を組み込みます。

# Nginx におけるメンテナンス切替設定例
# /var/www/maintenance.flag が存在する場合は強制的に503を返却
if (-f /var/www/maintenance.flag) {
    return 503;
}
error_page 503 /maintenance.html;

作業開始時にフラグファイルを配置して503を返却させ、マイナー更新完了および動作確認が完了した後にフラグファイルを削除してサービスを再開する手順を策定します。

4. 【実機検証】AlmaLinux 10でのアップデート実践と切り戻しテスト#

実機環境（alma-db01）を用いて、あえて旧バージョンであるPostgreSQL 18.4を初期構築した状態から、最新の18.6へのマイナーバージョンアップ、および万一のダウングレード切り戻しを検証します。

4.1 アップデート前の初期状態確認#

データベースproduction_dbにテスト用テーブルapp_recordsを作成し、18.4環境で3件のデータを投入しておきます。

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

$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "SELECT * FROM public.app_records;"
 id |        title        | created_version |          created_at           
----+---------------------+-----------------+-------------------------------
  1 | 運用マニュアル第1版 | 18.4            | 2026-09-09 20:51:53.221458+09
  2 | インフラ構成図      | 18.4            | 2026-09-09 20:51:53.221458+09
  3 | 監視アラート一覧    | 18.4            | 2026-09-09 20:51:53.221458+09
(3 行)

4.2 計画停止から dnf update によるバージョンアップ実行#

第5回で解説した通り、万一の障害に備えて事前バックアップを採取した上で、サービスを停止してパッケージを更新します。

# 1. 事前バックアップ採取
$ sudo -u postgres /usr/pgsql-18/bin/pg_dumpall -g -f /var/lib/pgsql/globals_pre_upgrade.sql
$ sudo -u postgres /usr/pgsql-18/bin/pg_dump -Fc -v -d production_db -f /var/lib/pgsql/production_db_pre_upgrade.dump

# 2. サービス停止
$ sudo systemctl stop postgresql-18

# 3. パッケージ更新
$ sudo dnf -y update postgresql18-server

# 4. サービス起動
$ sudo systemctl start postgresql-18

4.3 起動後のバージョン確認と既存データの完全保全確認#

サービス起動後、バージョン照合とデータの読み出しテストを実行します。

$ 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
(1 行)

$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "SELECT * FROM public.app_records;"
 id |        title        | created_version |          created_at           
----+---------------------+-----------------+-------------------------------
  1 | 運用マニュアル第1版 | 18.4            | 2026-09-09 20:51:53.221458+09
  2 | インフラ構成図      | 18.4            | 2026-09-09 20:51:53.221458+09
  3 | 監視アラート一覧    | 18.4            | 2026-09-09 20:51:53.221458+09
(3 行)

バージョン表記がPostgreSQL 18.6に更新されていること、および18.4稼働時に投入した3件のレコードが何の手間もなくそのまま整合性を保って参照できることが確認できました。

4.4 万一の不具合発生時：dnf downgrade による切り戻し検証#

「新マイナーバージョンに起因する予期せぬ不具合がアプリ側で発覚した」という想定で、旧バージョン（18.4）への切り戻しを実施します。

# 1. サービス停止
$ sudo systemctl stop postgresql-18

# 2. パッケージのダウングレード
$ sudo dnf -y downgrade \
    postgresql18-server-18.4-2PGDG.rhel10.2 \
    postgresql18-18.4-2PGDG.rhel10.2 \
    postgresql18-libs-18.4-2PGDG.rhel10.2

# 3. サービス起動
$ sudo systemctl start postgresql-18

ダウングレード完了後の状態を確認します。

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

$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "SELECT * FROM public.app_records;"
 id |        title        | created_version |          created_at           
----+---------------------+-----------------+-------------------------------
  1 | 運用マニュアル第1版 | 18.4            | 2026-09-09 20:51:53.221458+09
  2 | インフラ構成図      | 18.4            | 2026-09-09 20:51:53.221458+09
  3 | 監視アラート一覧    | 18.4            | 2026-09-09 20:51:53.221458+09
(3 行)

バイナリが旧マイナーバージョン（18.4）に安全に巻き戻され、正常稼働を回復できることが実証されました。

4.5 切り戻しにおけるデータ整合性の注意点#

4.6 リリースノート特定指示に基づく REINDEX 実機検証#

マイナーバージョンアップのリリースノートに「インデックス破損バグ修正に伴うREINDEX必須」の特記事項が記載されていたシナリオを想定し、新バージョン起動後のインデックス再構築手順を検証します。

通常の REINDEX TABLE は対象テーブルに対して ACCESS EXCLUSIVE ロックを取得するため、オンライン業務を完全にブロッキングしてしまいます。そこで、業務影響を排除するために CONCURRENTLY オプションを使用します。

-- 1. アプリケーション再開後、バックグラウンドで並行インデックス再構築を実行
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "
REINDEX TABLE CONCURRENTLY public.app_records;
"
REINDEX

-- 2. 再構築されたインデックスの健全性と有効性を確認
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "
SELECT indexrelname, indisvalid FROM pg_index i 
JOIN pg_stat_user_indexes u ON i.indexrelid = u.indexrelid 
WHERE u.relname = 'app_records';
"
   indexrelname    | indisvalid 
-------------------+------------
 app_records_pkey  | t
(1 行)

indisvalid = t（true）が確認でき、新しいマイナーバージョンの正しいB-Treeロジックに基づいてインデックスがオンラインで正常再構築されたことが実証されました。

5. 実務チートシート：意図せぬ自動更新を防ぐ versionlock 設定#

OSのパッケージ自動更新機能（dnf-automaticなど）や管理者の誤操作によってPostgreSQLが勝手に更新される事故を防ぐため、特定のバージョンでパッケージを固定（ロック）する設定方法をまとめます。

# 1. versionlock プラグインのインストール
$ sudo dnf install -y python3-dnf-plugin-versionlock

# 2. 現在のPostgreSQL 18パッケージをロック
$ sudo dnf versionlock add "postgresql18*"

# 3. ロック一覧の確認
$ sudo dnf versionlock list
postgresql18-server-0:18.6-4PGDG.rhel10.2.*
postgresql18-0:18.6-4PGDG.rhel10.2.*
postgresql18-libs-0:18.6-4PGDG.rhel10.2.*

# 4. バージョンアップ作業時にロックを解除する場合
$ sudo dnf versionlock delete "postgresql18*"

本番サーバーでは上記のようにロックをかけておき、計画メンテナンスの作業手順内でのみロックを解除して更新する運用がエンタープライズの標準です。

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

マイナーバージョンアップ作業において、現場のインフラエンジニアが直面しやすい典型的なトラブル3選と、その回避・対処手順を解説します。

6.1 事例1：dnf update 実行時のパッケージ依存関係エラー#

マイナー更新を実行した際、リポジトリのメタデータ不整合やサードパーティパッケージの競合により、以下のような依存関係エラーが発生することがあります。

Error: 
 Problem: cannot install the best update candidate for package postgresql18-server-18.4-2PGDG.rhel10.x86_64
  - nothing provides postgresql18-libs(x86-64) = 18.6-4PGDG.rhel10 needed by postgresql18-server-18.6-4PGDG.rhel10.x86_64

6.2 事例2：拡張モジュール（Extension）の関数ロードエラー#

PostGISや pg_stat_statements、pgaudit などのC言語で書かれた拡張モジュールを利用している場合、本体バイナリを更新した直後にクエリを実行すると incompatible library や undefined symbol エラーが発生することがあります。

マイナー更新ではABI互換性が極力維持されますが、拡張機能側にもマイナーアップデート版のRPMが提供されている場合は、必ず本体と同時に拡張機能RPMも更新します。また、更新後にデータベース内で以下のSQLを実行し、拡張機能の定義を最新化します。

-- 拡張機能の定義カタログを新バイナリに合わせて更新
ALTER EXTENSION pg_stat_statements UPDATE;
ALTER EXTENSION pgaudit UPDATE;

6.3 事例3：ダウングレード切り戻しにおける後退リスクと安全原則#

更新後に万一重大なアプリケーション不具合が発覚した場合、「安易にパッケージを dnf downgrade すれば安全に切り戻せる」と考えるのは本番運用において極めて危険です。

PostgreSQLのマイナーバージョン間ではディスクフォーマットおよびWAL形式の後方互換性が厳格に維持されていますが、新マイナーバージョン（例：18.6）で稼働してカタログ更新や拡張機能のアップデート、新パラメータの書き込みが行われたデータディレクトリに対して、古いバイナリ（例：18.4）を起動した場合、修正されたはずのデータ破損バグが再発したり、未定義の内部状態に陥る理論上のリスクを完全に排除できません。

6.4 事例4：pg_stat_statements 実行統計リセットの運用判断#

マイナーバージョンアップにおいてオプティマイザのバグ修正や性能改善が含まれていた場合、更新前と更新後でクエリの実行時間差分を正しく評価するために、蓄積されたクエリ統計情報をリセットするかどうかの判断が必要になります。

-- 1. 更新前の統計情報をログまたはテーブルへ退避
CREATE TABLE pre_upgrade_query_stats AS SELECT * FROM pg_stat_statements;

-- 2. 統計カウンタをゼロクリア
SELECT pg_stat_statements_reset();

過去の累計統計（call回数やmean_exec_time）が混ざったままだと、「新マイナーバージョン適用後にクエリ性能が向上したのか、あるいは新たなボトルネックが発生したのか」を正確に判別できません。本番サービス再開直前に統計をクリアし、新バージョン環境での初期数日間のクエリ傾向をクリーンに計測・監視することが推奨されます。

7. 実務チートシート：マイナーバージョンアップ計画・点検チェックリスト#

本番適用時のミスを防ぐため、作業前・作業中・作業後に実施すべき確認項目をチェックリストとして整理しました。

7.1 実務作業手順書の標準タイムテーブル設計例#

夜間計画メンテナンス枠（例：停止枠30分間）において、チーム作業を安全に進行させるための標準タイムライン設計例です。

このように、「何分までにどのステップが完了していなければ切り戻し（スナップショット復元）を開始するか」という「デッドライン（判断限界時刻）」を作業手順書に明記しておくことが、本番障害を未然に防ぐ鉄則です。

8. 理解度確認演習問題（全3問・解答解説付き）#

9. まとめと次回予告#

次回は第8回「【ダウンタイム極小化】PostgreSQLのメジャーバージョンアップ手順：pg_upgrade実務攻略」を解説します。物理フォーマット非互換の壁、新旧バージョンのバイナリ共存、–check による事前診断、–link（ハードリンク）によるテラバイト級DBの瞬時移行、そしてアップグレード後のオプティマイザ統計再収集を実機検証で整理します。