PostgreSQL 19 の新しいシステムビュー

PostgreSQL 19 のモニタリング機能強化についての記事を執筆し、10 月の PostgreSQL Conference Europe で行う Postgres のオブザーバビリティに関する新しい講演の準備を進める中で、今回のリリースではシステムビューが独立したセクションとして取り上げられていることに気づきました。このように大きく扱われたのは、PG13 と PG14 以来のことです。そこで、何が変わったのかを詳しく解説するために、システムビューを単独で取り上げるブログ記事を書くことにしました。PostgreSQL 19 では、pg_stat_lock、pg_stat_recovery、pg_stat_autovacuum_scores、pg_dsm_registry_allocations という 4 つの新しいビューが追加されました。これらはどれも、以前のモニタリングに関するブログでの 1 行の言及だけでは収まらない内容ですので、ここで詳しく見ていきましょう。

免責事項: 本記事の執筆時点で PostgreSQL 19 はまだベータ版であり、開発サイクルの途中でカラム名が変更された箇所もすでに存在します。一般提供 (GA) までに変更や差し戻しが行われる可能性があります。最新の正確な情報はリリースノートをご確認ください。

pg_stat_lock {#pg_stat_lock}

ロックは私が特に関心を持っている分野です 😀 2025 年には、「Anatomy of Table-Level Locks in PostgreSQL」というタイトルで 16 のカンファレンスで登壇しました。興味のある方は、その一部の録画が YouTube で公開されています。ですので、PostgreSQL 19 で新しいロック関連ビューが登場したのを見たときの私の興奮を想像していただけるでしょう。

これまで、ロック競合の状況を把握するための手段は pg_locks(現時点のスナップショットであり、履歴は保持されない)と log_lock_waits の出力(履歴は残るが、集計するにはログを自分で解析する必要がある。ただし、PostgreSQL 19 ではデフォルトで有効化されました。この変更は以前のモニタリングに関する記事で取り上げました)に限られていました。

PostgreSQL 19 では pg_stat_lock(Bertrand Drouvot 氏によるパッチ §)が追加されました。これは、ロックタイプ(locktype)ごとに 1 行で表される、クラスター全体を対象とした累積のロック統計情報です。locktype という名称は少し紛らわしいかもしれません。これはロックモード(ACCESS EXCLUSIVE や ROW SHARE など)ではなく、ロック対象のオブジェクト種別(何がロックされていたか)を表しており、次の 12 種類があります: relation、transactionid、tuple、extend、page、object、advisory、virtualxid、spectoken、applytransaction、frozenid、userlock。

このビュー自体は、新しい関数 pg_stat_get_lock() の薄いラッパーです。

表 1: pg_stat_lock ビュー

実際にクエリを実行してみましょう。ロック競合を再現するために 2 つの psql セッションを用意しました。最初のセッションでデモ用テーブルのロックを取得し、トランザクションを開いたまま保持します:

1-- session 1
2BEGIN;
3LOCK TABLE demo;
4SELECT pg_sleep(2.5);  -- hold the lock for 2.5 seconds
5COMMIT;

2 つ目のセッションで同じテーブルをロックしようとしますが、(セッション 1 がコミットするまで)ロックを取得できません:

1-- session 2
2LOCK TABLE demo;   -- waits here until session 1 commits

2.5 秒後、セッション 1 がコミットし、セッション 2 はようやくロックを取得します。この待機はデフォルトの deadlock_timeout である 1 秒を超えて継続し、最終的に取得に成功したため、カウント対象になります。これを確認するために、ビューにクエリを実行してみましょう:

デモを始める前に pg_stat_reset_shared('lock') でロック統計情報をリセットしたため、以下の数値はこのシナリオのみに由来するものです。

1SELECT waits, wait_time
2FROM pg_stat_lock
3WHERE locktype = 'relation';

1waits | wait_time
2-------+-----------
3    1 |  2201.783
4(1 row)

この結果は、セッション 2 がロックを取得するまでに 2.2 秒(セッション 1 がテーブルを占有していた 2.5 秒のうち)待機しなければならなかったことを示しています。0.3 秒の差は、セッション 1 がロックを取得してからセッション 2 がロックを要求するまでのわずかなタイムラグによるものです。

本番システムでは単一の待機だけを追跡することはないため、待機回数と合わせてロックタイプを問い合わせることになります:

1SELECT locktype, waits, wait_time,
2      round(wait_time::numeric / NULLIF(waits, 0), 1) AS avg_wait_ms
3FROM pg_stat_lock
4WHERE waits > 0
5ORDER BY wait_time DESC;

1locktype | waits | wait_time | avg_wait_ms
2----------+-------+-----------+-------------
3relation |     1 |  2201.783 |      2201.8
4(1 row)

fastpath_exceeded

pg_stat_lock ビューの fastpath_exceeded カウンターは掘り下げる価値があると考え、独立したセクションを設けました 🙂 速度を向上させるため、各バックエンドは競合がめったに発生しない最も一般的なロック向けに、小規模なファストパススロットのセットを保持しています。クエリが必要とするロック数がそのスロットの保持量を超えると、超過分はより低速な共有ロックテーブルへとフォールバックし、このカウンターが加算されます(deadlock_timeout のしきい値判定はなく、超過のたびに毎回カウントされます)。

fastpath_exceeded は、単一のクエリが多数のリレーションをロックする必要があるパーティション多用のワークロードにおいて、特に有用な指標となり得ます。

デモをわかりやすくするために、ファストパススロットの容量を超えるパーティション数を持つパーティションテーブルを作成してみましょう。新しいデフォルト値である 128 を上回る 140 パーティションを選択しました。(Postgres 自身のリグレッションテストでも同様の手法が用いられており、max_locks_per_transaction + 10 個のパーティションが作成されます。)

1CREATE TABLE part_demo (id int) PARTITION BY RANGE (id);
2
3DO $$
4BEGIN
5  FOR i IN 1..140 LOOP
6    EXECUTE format(
7      'CREATE TABLE part_demo_%s PARTITION OF part_demo
8      FOR VALUES FROM (%s) TO (%s)',
9      i, (i-1)*1000, i*1000);
10  END LOOP;
11END $$;

正確に計測するためにカウンターを再度リセットし、テーブルを 1 回スキャンします。単純な SELECT count(*) でも、親テーブルとすべてのパーティションをロックする必要があります:

1SELECT pg_stat_reset_shared('lock');
2SELECT count(*) FROM part_demo;

ここで、ビューにクエリを実行してみます:

1SELECT locktype, fastpath_exceeded
2FROM pg_stat_lock
3WHERE fastpath_exceeded > 0;

1locktype | fastpath_exceeded
2----------+-------------------
3relation |               422
4(1 row)

カウントが 140 を超えているのは、Postgres が上限を超えたロック取得の試行をすべてカウントしており、プランニング時と実行時の両方でパーティションがロックされる可能性があるためです。具体的な数値は実行ごとに変動することがありますが、重要なのはゼロではないという点であり、このワークロードがファストパスからあふれていることを示しています。

pg_stat_recovery {#pg_stat_recovery}

スタンバイのヘルスチェックを構築したことがある方なら、スタンバイの状態を確認するために pg_is_in_recovery()、pg_last_wal_replay_lsn()、pg_last_xact_replay_timestamp()、pg_get_wal_replay_pause_state() の一部またはすべてを使ったことがあるはずです。これらの関数はそれぞれ独自のロック下で、わずかに異なるタイミングで共有リカバリ状態を読み取ります。私たち DBA が以前よく行っていたように、これらを 1 つのビューにまとめたとしても、呼び出しの合間にもリプレイが進み続けるため、それぞれの値の間で整合性が保たれている保証はありません。

pg_stat_recovery(Xuneng Zhou 氏 §、加藤真也氏による修正 §)は、これらの情報を単一のアトミックなスナップショットとして読み出し、1 行に集約することで、すべてのフィールドの整合性を担保します。

表 2: pg_stat_recovery ビュー

1SELECT last_replayed_end_lsn, last_replayed_tli,
2      recovery_last_xact_time, pause_state, promote_triggered
3FROM pg_stat_recovery;

1last_replayed_end_lsn | last_replayed_tli |    recovery_last_xact_time    | pause_state | promote_triggered
2-----------------------+-------------------+-------------------------------+-------------+-------------------
30/03001E20            |                 1 | 2026-08-31 15:43:27.762621+02 | not paused  | f
4(1 row)

実践における注意点をいくつか挙げます:

• このビューはプライマリ上では行を返さないため、スタンバイ上でクエリを実行する必要があります。
• データを閲覧するには pg_read_all_stats 権限が必要です。
• 従来の関数も引き続き利用可能であり、本機能は純粋な追加要素です。

HA(高可用性)ツールをメンテナンスしている方にとって、今回はアップデートを行う良い機会です。数秒ごとにヘルスチェックを実行している場合、複数のクエリを実行する代わりに 1 つのクエリでリカバリ状態の整合したビューを取得できることは、地味ながらも嬉しい改善です。

pg_stat_autovacuum_scores {#pg_stat_autovacuum_scores}

このセクションでは、autovacuum の新しい動作と、それを監視するためのビュー(pg_stat_autovacuum_scores)の 2 つの変更点を取り上げます。

まず、動作の変更についてです。PostgreSQL 19 では、autovacuum がどのテーブルから優先して処理するかを決定する方法が変わりました。PostgreSQL 19 より前では、autovacuum は pg_class 内で見つかった順序でテーブルを処理していました。今回の変更により、各ワーカーはテーブルごとに、XID 年齢、multixact 年齢、不要タプル(dead tuples)、挿入、analyze の鮮度といった autovacuum の各しきい値にどれだけ近づいているか(あるいはどれだけ超過しているか)に基づいてスコアを算出するようになりました。最も高いスコアを持つテーブルが優先されるため、最も対処が必要なテーブルから順に処理されます。

5 つの新しい autovacuum_*_score_weight パラメータ(すべてデフォルトは 1.0)により、各要素の重み付けを設定できます。これらをすべて 0.0 に設定すると、PostgreSQL 19 より前の順序に戻ります。Nathan Bossart 氏のコミットでは、これを「よりスマートな autovacuum ワーカーに向けた第一歩」と呼んでいます。

2 つ目の変更点は、これらの統計情報を可視化する機能です。pg_stat_autovacuum_scores(Sami Imseih 氏 §)は、現在のデータベース内のテーブルごと(TOAST テーブルやシステムカタログを含む)にこれらのスコアを公開し、autovacuum がどのテーブルを優先しているかを明らかにします。

表 3: pg_stat_autovacuum_scores ビュー

動作を確認するために、いくつかクエリを実行してみましょう。1,000 行のテーブルを作成して analyze を実行し、400 行を削除しました:

1CREATE TABLE av_demo AS
2  SELECT g AS id, md5(g::text) AS payload FROM generate_series(1, 1000) g;
3ANALYZE av_demo;
4DELETE FROM av_demo WHERE id <= 400;

次に、pg_stat_autovacuum_scores ビューに対して、autovacuum がこのテーブルをどのように評価しているかを問い合わせます:

1SELECT relname, round(score::numeric,2) AS score,
2      do_vacuum, do_analyze, for_wraparound
3FROM pg_stat_autovacuum_scores
4WHERE schemaname = 'public' AND (do_vacuum OR do_analyze)
5ORDER BY score DESC;

1relname | score | do_vacuum | do_analyze | for_wraparound
2---------+-------+-----------+------------+----------------
3av_demo |  2.67 | t         | t          | f
4(1 row)

2.67 という数値はどこから来たのでしょうか？ autovacuum はテーブルの行数から算出されるしきい値を用いて実行タイミングを判断します。analyze の場合、デフォルトは 50 + 0.1 × 行数となるため、この 1,000 行のテーブルでは 150 です。今回は 400 行を変更したため、analyze スコアは 400 / 150 = 2.67 になります。

削除処理によって vacuum のしきい値も超えています: 50 + 0.2 × 1000 = 250 となり、400 / 250 = 1.60 になります。総合スコアは各要素の中で最も高い値が採用されるため、av_demo のスコアは 2.67 となり、vacuum と analyze の両方の対象となります。

for_wraparound は行の変更数ではなく、まったく別の計算、つまり年齢に基づいています。具体的には、テーブルの最も古い未フリーズのトランザクション ID が、autovacuum_freeze_max_age(デフォルトは 2 億トランザクション)に向けてどの程度進んでいるかを示します。新しく作成したテーブルはそのしきい値から遠く離れているため、false になります。

pg_dsm_registry_allocations {#pg_dsm_registry_allocations}

規模は小さめですが便利な機能を紹介します。拡張機能による共有メモリの割り当てにおいて DSM レジストリの利用が増えており、共有メモリを確保するためだけに shared_preload_libraries を設定(および再起動)する必要がなくなってきています。しかしこれまで、そのメモリは SQL から確認できませんでした。

この新しい pg_dsm_registry_allocations ビュー(Florents Tselai 氏 §、Nathan Bossart 氏による機能拡張 §)は、各レジストリエントリの名前、タイプ(segment、area、hash)、およびサイズを一覧表示します。サイズが NULL の場合は、そのエントリの初期化に失敗したことを意味します。

表 4: pg_dsm_registry_allocations ビュー

まとめ {#outro}

最後までお読みいただきありがとうございました！ 新しいシステムビューの登場を、私と同じように楽しみにしていただければ幸いです。PostgreSQL 19 のリリースが待ち遠しいですね。皆さんの今後のスムーズなアップグレードを応援しています！

10 月の PostgreSQL Conference Europe では、PostgreSQL 19 のオブザーバビリティについて講演する予定であり、本記事で取り上げたトピックもいくつか登場します。バレンシアにいらっしゃる予定の方は、ぜひ気軽にお声がけください！ 👋