この記事では、PostgreSQL（RHEL系環境）において、再起動せず・低リスクでDB操作ログを取得する方法を、
汎用的なケースに即して解説します。
あわせて、
- 今回の設定で「どこまで確認できるか」
-
pgauditを導入した場合との メリット・デメリット比較
も整理します。
背景・よくある要件
運用現場では、次のような要件がよくあります。
- 管理ユーザー（postgres）のDDL操作を記録したい
- 障害調査時に、特定のアプリユーザーのSELECTを一時的に追いたい
- 本番DBは再起動したくない
- ログは必要最小限に抑えたい
本記事では、標準機能のみで実現する方法を扱います。
基本方針（設計思想）
ポイントは次の3点です。
- postgresql.conf では全体ログを抑制
- ユーザー単位（ROLE単位）でログ出力を制御
- 変更はすべて 可逆（すぐ元に戻せる）
これにより、本番環境でも安全に運用できます。
手順① postgresql.conf の最小設定
方針
- 全体では SQL 文を出力しない
- 接続／切断ログのみ有効化
設定例（抜粋）
# 接続ログ
log_connections = on
log_disconnections = on
# SQLログはROLE側で制御
log_statement = 'none'
⚠️ 既存の設定は削除せず、必要に応じてコメントアウトするのが安全です。
反映
SELECT pg_reload_conf();
※ 再起動は不要
手順② 管理ユーザー（postgres）の操作ログ取得
DDLのみを記録する
ALTER ROLE postgres SET log_statement = 'ddl';
記録される例
- CREATE / ALTER / DROP
- INDEX 作成
- VACUUM / ANALYZE
記録されない例
- SELECT
- INSERT / UPDATE / DELETE
👉 ログ出力のディスク使用量を考慮して記録対象を制限（ケースバイケースで調整する）
手順③ アプリユーザーのSELECTを一時的に取得
調査時のみ有効化
ALTER ROLE app_user SET log_statement = 'all';
調査終了後
ALTER ROLE app_user SET log_statement = 'none';
- 再起動不要
- 次回接続から有効
- Pgpool / コネクションプール使用時は再接続が必要
今回の設定で「確認できる範囲」
| 対象 | 確認可否 | 備考 |
|---|---|---|
| DB接続／切断 | ○ | 全ユーザー |
| postgresのDDL | ○ | ALTER ROLE ddl |
| postgresのSELECT | △ | all指定時のみ |
| アプリSELECT | ○ | 一時的に可 |
| バインド値 | × | SQL文字列のみ |
| 権限チェック結果 | × | 監査対象外 |
pgaudit との比較
機能比較表
| 項目 | 今回の方法（標準） | pgaudit |
|---|---|---|
| 再起動不要 | ○ | ×（要再起動） |
| 依存モジュール | なし | あり |
| 設定の簡単さ | ◎ | △ |
| ログ粒度 | △ | ◎ |
| SELECT制御 | ○ | ○ |
| 権限チェック監査 | × | ○ |
| 本番影響リスク | 低 | 中 |
比較イメージ
標準ログ方式
└─ 接続／DDL／必要時SELECT
└─ 低リスク・即時切替
pgaudit
└─ ROLE / DDL / READ / WRITE
└─ 高監査性・高ログ量
どちらを選ぶべきか？
今回の方法が向いているケース
- 本番DBを止められない
- 監査よりも運用・調査重視
- ログ量を抑えたい
pgaudit が向いているケース
- 内部統制・SOX・ISMS対応
- 誰が何を「参照」したかまで必要
- 専用監査ログが必須
まとめ
- ALTER ROLE を使ったログ制御は安全・柔軟・可逆
- conf は最小限、運用で切り替えるのがコツ
- 監査要件が厳しくなったら pgaudit を検討
補足
- PostgreSQL 13以降で同様に利用可能
- RHEL / Rocky / Alma Linux 共通
- Pgpool-II 環境でも有効（再接続注意）