対象バージョン: PostgreSQL 16 / 17（本記事の確認方法は PostgreSQL 9.5 以降で利用できます）
1. はじめに
前回の記事では postgresql.conf の主要パラメータと推奨値を整理しました。今回はその続きとして、設定した値が実際にデータベースへ反映されているかを確認する方法を解説します。
postgresql.conf を編集しても、その内容が即座に効くとは限りません。パラメータによっては「再起動するまで反映されない」ものがあり、また記述ミスがあっても起動はするが無視される、というケースもあります。「設定したつもり」で負荷テストに臨み、後から「実は値が変わっていなかった」と気づくのは、性能試験で最も避けたい失敗です。
そこで本記事では、現在の値を確認するコマンド、反映タイミングの見分け方、記述ミスの検知方法までを順に押さえていきます。対象は前回同様、データベースのチューニングに取り組む初心者〜中級者です。
2. 現在の設定値を確認する
2.1 確認方法の一覧
稼働中のPostgreSQLが「今どの値で動いているか」を確認する方法は主に3つあります。
| 方法 | 用途 |
|---|---|
SHOW | 1つ（または全部）の値を人間が読みやすい形で手早く見る。 |
current_setting() | SQLの式の中で値を文字列として取得する。 |
pg_settings ビュー | 値だけでなく、反映タイミングや設定の出どころまで詳しく調べる。 |
普段の確認は SHOW、詳しく調べたいときは pg_settings、という使い分けがおすすめです。
2.2 SHOW コマンド
最も手軽な方法です。パラメータ名を指定すると、単位付きの読みやすい値が返ってきます。
-- 個別に確認する
SHOW shared_buffers; -- 4GB
SHOW work_mem; -- 16MB
SHOW max_connections; -- 150
-- すべて確認する（量が多いので注意）
SHOW ALL;SQLの式の中で使いたい場合は current_setting() を使います。
SELECT current_setting('shared_buffers'); -- '4GB'2.3 pg_settings ビュー
SHOW は値そのものを見るだけですが、pg_settings ビューを使うと「いつ反映されるのか」「どのファイルで設定されたのか」まで分かります。確認作業の主役はこちらです。
SELECT name, setting, unit, context, source, pending_restart
FROM pg_settings
WHERE name IN (
'shared_buffers',
'effective_cache_size',
'work_mem',
'maintenance_work_mem',
'max_connections'
);主に見るカラムは次のとおりです。
| カラム | 意味 |
|---|---|
setting | 現在の値（後述のとおり単位は unit カラムで決まる）。 |
unit | setting の単位（8kB、kB、ms など）。 |
context | 値が反映されるタイミング（最重要。次章で解説）。 |
source | 値の出どころ（default / configuration file など）。 |
pending_restart | 再起動待ちかどうか（true なら未反映）。 |
sourcefile / sourceline | どのファイルの何行目で設定されたか。 |
3. 反映タイミングを理解する（context カラムが鍵）
「設定したのに反映されない」の正体は、ほとんどがこの context カラムにあります。パラメータごとに反映に必要な操作が決まっており、それが context で表現されています。
3.1 context の種類と意味
確認時によく目にするのは次の4つです。
| context | 反映に必要な操作 |
|---|---|
internal | コンパイル時に固定。変更不可。 |
postmaster | サーバーの再起動が必要。 |
sighup | 設定リロードで反映（再起動は不要）。 |
user / superuser | リロードで反映。さらにセッション単位で SET でも変更できる。 |
ポイントは、postmaster だけが再起動を要求するという点です。それ以外はリロードで足ります。
3.2 主要パラメータの反映タイミング早見表
前回の記事で扱ったパラメータを、反映タイミングで分類すると次のようになります。
| パラメータ | context | 反映方法 |
|---|---|---|
shared_buffers | postmaster | 再起動 |
max_connections | postmaster | 再起動 |
wal_buffers | postmaster | 再起動 |
effective_cache_size | user | リロード |
work_mem | user | リロード（SET も可） |
maintenance_work_mem | user | リロード（SET も可） |
autovacuum_work_mem | sighup | リロード |
log_min_duration_statement | superuser | リロード |
log_lock_waits | superuser | リロード |
deadlock_timeout | superuser | リロード |
メモリ周りの主役である shared_buffers と max_connections が再起動必須である点は、特に注意が必要です。サーバーのスケールアップに合わせてこれらを変更した場合、リロードだけでは効きません。
4. 設定を反映させる（リロードと再起動）
4.1 リロードで反映できるもの
context が sighup / superuser / user のパラメータは、リロードだけで反映できます。接続を切らずに済むため、本番でも比較的安全に適用できます。
-- SQLから実行する
SELECT pg_reload_conf();# OSのコマンドから実行する
sudo systemctl reload postgresql4.2 再起動が必要なものと pending_restart
context が postmaster のパラメータは、ファイルを書き換えてリロードしても反映されません。この「リロードしたが再起動待ち」の状態を検知してくれるのが pending_restart カラムです。
-- 再起動待ちのパラメータだけを一覧表示する
SELECT name, setting, pending_restart
FROM pg_settings
WHERE pending_restart;このクエリで行が返ってきたら、まだ反映されていない設定があるということです。再起動を実施します。
sudo systemctl restart postgresql再起動後にもう一度同じクエリを実行し、結果が0件になっていれば反映完了です。
分析ステップ：
SHOWで現在の値が期待どおりか確認する。- 値が変わっていなければ
pg_settingsのcontextを確認する。 contextがpostmasterであれば、pending_restartを確認のうえ再起動する。- それ以外であれば、リロード漏れを疑い
pg_reload_conf()を実行する。
5. 設定ファイルの記述ミスを検知する（pg_file_settings）
パラメータ名のタイプミスや単位の書き間違いがあると、その行は静かに無視されることがあります。リロードする前に記述ミスを検知できるのが pg_file_settings ビューです。
-- 記述に問題がある行だけを抽出する
SELECT sourcefile, sourceline, name, setting, applied, error
FROM pg_file_settings
WHERE error IS NOT NULL;設定方針： error カラムに値が入っている行は、リロードしても適用されません。リロードや再起動の前にこのクエリを実行し、結果が0件であることを確認してから反映するのが安全です。
実践テクニック： 同じパラメータを複数の場所で重複して書いてしまった場合、後に書いた値が優先され、先に書いた行は applied = false になります。「設定したはずの値が効かない」ときは、重複定義を疑って applied カラムを確認すると原因が見つかることがあります。
-- 重複などで適用されていない行を確認する
SELECT sourcefile, sourceline, name, setting, applied
FROM pg_file_settings
WHERE applied = false;6. 単位の読み方（よくある落とし穴）
pg_settings の setting カラムを見て「値がおかしい」と勘違いしやすいのが、この単位の問題です。
SHOW は人間が読みやすい単位（4GB など）で表示しますが、pg_settings.setting は内部表現の数値で、その単位は unit カラムに書かれています。
SELECT name, setting, unit FROM pg_settings WHERE name = 'shared_buffers';
-- name | setting | unit
-- shared_buffers | 524288 | 8kBこの場合、setting は 524288、unit は 8kB なので、実際の値は次のように計算します。
524288 × 8kB = 4,194,304 kB = 4GBつまり SHOW shared_buffers; の結果（4GB）と一致します。setting の生の数値だけを見て驚かないよう、必ず unit とセットで読むのがポイントです。shared_buffers / effective_cache_size / wal_buffers は単位が 8kB、work_mem / maintenance_work_mem は kB、ログ系の時間設定は ms である点も押さえておきましょう。
7. ALTER SYSTEM と postgresql.auto.conf
PostgreSQLでは、SQLから設定を変更する ALTER SYSTEM も使えます。
ALTER SYSTEM SET work_mem = '16MB';
SELECT pg_reload_conf();注意したいのは、この変更が postgresql.conf ではなく postgresql.auto.conf という別ファイルに書き込まれる点です。そして auto.conf は postgresql.conf より優先されます。
そのため「postgresql.conf を編集したのに値が変わらない」というときは、過去に ALTER SYSTEM で設定した値が auto.conf に残っていて上書きされている、というケースがあります。値の出どころは pg_settings の source / sourcefile カラムで確認できます。
SELECT name, setting, source, sourcefile
FROM pg_settings
WHERE name = 'work_mem';source が configuration file で sourcefile が postgresql.auto.conf を指していれば、その値は auto.conf 由来ということです。意図しない上書きを取り消したい場合は ALTER SYSTEM RESET を使います。
ALTER SYSTEM RESET work_mem;
SELECT pg_reload_conf();8. 実践：変更を確認するチェックリスト
設定変更から反映確認までの流れを、手順としてまとめます。
postgresql.confを編集する。pg_file_settingsでerrorが無いことを確認する（記述ミスの検知）。- リロード（
pg_reload_conf()）または再起動を実施する。 pg_settingsでsetting・unit・sourceを確認し、期待どおりの値・出どころか検証する。pending_restartに行が残っていないことを確認する（再起動漏れの検知）。- 最後に
SHOWで人間可読の値を確認し、ダブルチェックする。
この流れを踏んでおけば、「設定したつもりで効いていなかった」という事故をほぼ防げます。負荷テストの直前には、特に shared_buffers や max_connections のような再起動必須パラメータの pending_restart を確認しておくと安心です。
9. まとめ
設定値は「書いて終わり」ではなく、「反映されたかを確認して終わり」です。
- 現在の値は
SHOWで手早く、詳細はpg_settingsで確認する。 - 反映タイミングは
contextカラムで判断する。postmasterだけは再起動が必要。 - 記述ミスは
pg_file_settingsで、再起動漏れはpending_restartで検知する。 settingの生の数値はunitとセットで読む。- 意図しない値が残っていないか、
sourceで出どころを確認する。
設定の確認は地味な作業ですが、性能試験の信頼性を支える土台になります。チューニングした値を効かせた状態で、負荷テストに臨んでみてください。
コメント