変更要約: 初版(主題S2・S2.1〜S2.5)
2.3設定ファイル
サーバー全体の挙動を決めるpostgresql.conf(記述方法・単位・include/接続と認証のlisten_addresses・port・max_connections/ログのlogging_collector・log_destination)と、クライアントごとの認証方式を定めるpg_hba.conf(trust・md5・scram-sha-256・peer、行の記述順)、そして実行時に値を確認・変更するSET・SHOWを学びます。
PostgreSQLの挙動は主に2つの設定ファイルで決まります。サーバー自体の動作を定めるpostgresql.confと、誰がどう認証されて接続できるかを定めるpg_hba.confです。役割が明確に分かれているため、「この設定はどちらのファイルか」を正確に区別できることが実務・試験の両方で重要です。
2.3.1postgresql.conf
- postgresql.conf=
パラメータ名 = 値形式で1行1設定を記述するサーバー全体の設定ファイル。#で始まる行はコメント。値にはメモリサイズ等の単位(MB・GB等)を付けられ、他の設定ファイルを取り込むinclude(またはinclude_dir)で分割管理もできます。 - 接続と認証:listen_addresses=サーバーが待ち受けるネットワークインターフェース(
localhostのみか*で全許可か等)。port=待ち受けTCPポート(既定5432)。max_connections=同時接続数の上限。これらは変更に再起動が必要な代表的パラメータです。 - エラー報告とログ:logging_collector=ログを専用のログファイルへ書き出す収集プロセスを有効化するか(
onで有効)。log_destination=ログの出力先形式(stderr・csvlog・syslog等)を指定します。
2.3.2pg_hba.conf と SET/SHOW
- pg_hba.conf=クライアント認証を定める設定ファイル(hba=host-based authentication)。1行が「接続種別・データベース・ユーザー・接続元アドレス・認証方式」の組で、複数行が上から順に照合され、最初に一致した行の認証方式が採用されるため、行の記述順が極めて重要です。
- 認証メソッド:trust=パスワード等の確認なしで無条件に許可(最も緩い・信頼できる閉域網以外で使うのは危険)。md5=MD5ハッシュ化されたパスワード認証(伝統的な方式)。scram-sha-256=より強固なSCRAM-SHA-256方式によるパスワード認証(PostgreSQL 10以降の推奨)。peer=OS側のユーザー名とPostgreSQLのロール名を突き合わせる方式(ローカルソケット接続限定)。
- SET=現在のセッションの実行時パラメータを一時的に変更するSQLコマンド(セッション終了で元に戻る)。SHOW=現在有効なパラメータの値を確認・表示するSQLコマンド(
SHOW ALLで一覧表示)。
「pg_hba.confは上から順に照合し最初に一致した行が採用される」「trustは無条件許可で最も緩い・scram-sha-256が最も強固」「peerはローカル接続限定でOSユーザーとロール名を突き合わせ」「listen_addresses/port/max_connectionsは再起動要」「SETはセッション限定の一時変更・SHOWは確認のみ」が最頻出です。postgresql.confとpg_hba.confの役割の取り違えも定番の誤答パターンです。
新規導入したPostgreSQLサーバーに、社内の別ホストからアプリケーションを接続させる設定変更を追ってみましょう。まずpostgresql.confでlisten_addresses = '*'(全インターフェースで待ち受け)に変更し、必要ならportも明示します。これらは再起動が必要なパラメータなので、変更後はpg_ctl restartで反映させます。次に、実際に「どのクライアントが・どのユーザーで・どう認証されて」接続できるかをpg_hba.confで定めます。たとえば社内ネットワーク192.168.1.0/24からの接続にはscram-sha-256によるパスワード認証を要求し、サーバー自身が動くローカルホストからの管理用接続にはpeer(OSユーザーとロール名の一致)を許可する、という具合に用途ごとに異なる行を追加します。ここで見落としがちなのが行の順序です。pg_hba.confは上から順に評価され最初に一致した行が使われるため、たとえば汎用的な0.0.0.0/0をtrustで許可する行を誤って社内限定の厳格な行より上に書いてしまうと、意図せず全世界からの無条件アクセスを許してしまいます。設定変更後は、サーバー全体の再起動は不要で、pg_ctl reload(または管理者権限でのSELECT pg_reload_conf())だけで反映されます。最後に、動作確認としてSHOW listen_addresses;やSHOW port;で現在の実効値を確認し、一時的に特定セッションだけログレベルを変えて調査したい場合はSET log_min_duration_statement = 0;のようにそのセッション限りの調整を行う、という組み合わせが実務の定石です。
| 認証方式 | 確認内容 | 特徴 |
|---|---|---|
| trust | 確認なし | 無条件許可・最も緩い |
| md5 | MD5ハッシュ化パスワード | 伝統的な方式 |
| scram-sha-256 | SCRAM-SHA-256パスワード | 最も強固・PG10+推奨 |
| peer | OSユーザー名とロール名の一致 | ローカル接続限定 |
ひっかけ: 「pg_hba.confは条件が最も具体的な行が優先される」は誤りです。評価は必ず上から順で、最初に一致した行が採用され、後続にどれだけ具体的な行があっても無視されます。また「listen_addressesやmax_connectionsの変更もpg_ctl reloadだけで反映される」も誤り=これらは再起動が必要な代表的パラメータです。さらに「SETで変更した値はサーバーを通じて恒久的に有効になる」も誤り=SETは現在のセッション限りの一時的変更で、恒久設定はpostgresql.confを編集します。
2.3.3この節のまとめ
- postgresql.conf=サーバー全体の設定(
パラメータ=値・単位・include)。listen_addresses/port/max_connectionsは再起動要・logging_collector/log_destinationでログ制御 - pg_hba.conf=クライアント認証、上から順に評価し最初の一致が採用。trust(最も緩い)/md5/scram-sha-256(最も強固)/peer(ローカル限定)
- SET=セッション限定の一時変更・SHOW=現在値の確認(
SHOW ALLで一覧)
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. pg_hba.conf に複数の行を設定したところ、意図した認証方式が適用されず、より緩い方式が使われてしまった。原因として最も可能性が高いのは?
Q2. サーバーが待ち受けるネットワークインターフェースを変更し、外部ホストからの接続を許可したい。listen_addresses を変更した後、必要な作業は?
Q3. 調査のため、現在のセッションだけ一時的にログの詳細度を変更したい。サーバー全体の恒久設定には影響を与えたくない場合、使うべきSQLコマンドは?

