【入門編】pgAdmin 4の「Debugger」プラグインが動かない・有効化できない時のトラブルシューティングとpgAgent設定手順 – データベース・API管理活用バイブル

こんにちは!データベースと日々格闘していると、「ストアドプロシージャのどこでバグっているのか分からない……」と頭を抱えた経験、ありませんか?

本番環境の一歩手前で複雑なロジックを組むとき、printデバッグ(RAISE NOTICE)だけでは限界が来ます。そこで絶対に必要になるのが、PostgreSQLのGUI管理ツール「pgAdmin 4」に備わっている「Debuggerプラグイン」と、バックグラウンド処理を担う「pgAgent」です。

しかし、この2つ、いざ導入しようとすると「なぜか動かない」「メニューがグレーアウトしている」という罠にハマりがちです。

今回は、数々の現場でエンジニアを救ってきた私から、このトラブルの完全な解決策と、明日から即戦力となるセットアップの極意を優しく丁寧に伝授します。これをマスターすれば、あなたのデバッグ作業は劇的に楽になりますよ!

—

1. デバッグ環境の全体像を理解しよう

まず、「なぜプラグインがすんなり動かないのか」の理由を俯瞰しておきましょう。

pgAdminのDebuggerは、単に画面上のボタンを押して動くものではありません。
1. PostgreSQLサーバー側に「プラグインのバイナリ」がロードされていること
2. データベースごとに「拡張機能(Extension)」として有効化されていること
3. pgAdmin 4から適切な権限で接続されていること

この3つのピースが完璧に噛み合って初めて、ブレークポイント(一時停止)を貼って変数を覗き見ることができるようになります。

—

2. 最初の難関:Debuggerプラグインが動かない・有効化できない時の解決策

「プラグインを有効化しようとしたらエラーが出る」「メニューが消えている」というときの、現場で最も多い原因と処方箋を解説します。

ステップ1:`shared_preload_libraries` の設定ミスを正す

Debugger(内部的には `pldbgapi`)は、PostgreSQLのコアに深く食い込むモジュールです。そのため、サーバー起動時にメモリへ読み込ませる必要があります。

PostgreSQLの設定ファイル `postgresql.conf` を開き、以下の設定を確認・修正してください。

postgresql.conf
複数のライブラリを指定する場合はカンマ区切りにします
shared_preload_libraries = ‘$libdir/pldbgapi’

※注意:すでに他のライブラリ(pg_stat_statementsなど)を指定している場合は、カンマで繋いで追記してください。

書き換えたら、PostgreSQLサービスの再起動が必要です。

Ubuntu/Debianの場合
sudo systemctl restart postgresql

Windowsの場合(サービスマネージャーまたは管理者cmd)
net stop postgresql-x64-15
net start postgresql-x64-15

「ここを再起動し忘れる」というのが、新人・ベテラン問わず一番やりがちなミスです。

ステップ2:データベースへの拡張機能(Extension)の適用

サーバー側でロード準備ができたら、次はデバッグしたい個別のデータベースに対して有効化の呪文を唱えます。

pgAdminの「Query Tool」を開き、対象のデータベース上で以下のSQLを実行してください。

— デバッガー用の拡張機能を有効化
CREATE EXTENSION IF NOT EXISTS pldbgapi;

もしここで「そんなモジュールねぇよ(could not access file …)」というエラーが出たら、PostgreSQLのコントリビューションパッケージ(`postgresql-contrib` など)がOSにインストールされていません。yumやaptで追加インストールしてから再挑戦してください。

—

3. pgAgentの設定手順:バックグラウンド自動化の要

次に、定期実行や非同期タスクに欠かせない「pgAgent」のセットアップです。pgAgentは、PostgreSQL上で動くジョブスケジューラです。

ステップ1:pgAgent用スキーマの作成

pgAgentは、ジョブのスケジュール情報をデータベース内に保存します。そのため、専用のスキーマ(テーブル群)をインポートする必要があります。

1. pgAdminのオブジェクトツリーから、pgAgentを導入したいデータベースを選択します。
2. メニューの 「Tools」 > 「Query Tool」 を開きます。
3. 以下のSQLを実行して、pgAgentの仕組みをデータベースにインストールします。

— pgAgentの拡張機能を有効化(PostgreSQL 10以降の標準的な方法)
CREATE EXTENSION IF NOT EXISTS pgagent;

※以前のバージョンではsqlファイルを流し込む必要がありましたが、現在は拡張機能として一発で入ります。便利な世の中になりましたね!

ステップ2:OS側(バックグラウンド)でのデーモン起動

データベース側に器を作っても、それを監視して実行する「エンジン」をOS側で動かさなければジョブは動きません。これがpgAgent設定の二つ目のハマりポイントです。

サーバーのターミナル(またはコマンドプロンプト)から、以下のコマンドでpgagentプロセスを常駐させます。

接続文字列を指定してpgagentをバックグラウンド起動
host=localhost dbname=your_db user=postgres password=your_password
pgagent host=localhost dbname=mydb user=postgres

本番運用では、これを `systemd` や Windowsサービスに登録し、OS起動時に自動で立ち上がるように設定します。

—

4. 精度高い「HelloWorld」:ストアドプロシージャのデバッグを体験しよう

さあ、環境が整いました。実際に簡単なストアドプロシージャを作り、ブレークポイントを張ってデバッグしてみましょう。

以下のコードをpgAdminのQuery Toolで実行し、テスト用の関数を作成します。

— デバッグテスト用の簡単な関数
CREATE OR REPLACE FUNCTION public.fn_add_numbers(a integer, b integer)
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE
result integer;
BEGIN
— ここにブレークポイントを張ってみましょう
result := a + b;

RAISE NOTICE ‘計算結果は % です’, result;

RETURN result;
END;
$$;

デバッグ実行の手順

1. pgAdminのオブジェクトツリーで、今作成した関数 `fn_add_numbers(integer, integer)` を探します。
2. 関数を右クリックし、「Debugging」 > 「Debug」 を選択します。(または、関数を選択した状態でデバッグアイコンをクリック)
3. パラメータ入力画面が出るので、`a` に `10`、`b` に `20` を入力して「OK」を押します。
4. おめでとうございます! 画面がデバッグモードに切り替わり、コードの行頭で実行が一時停止(ブレーク)しているはずです。

画面右側の「Local variables」パネルに `a = 10`、`b = 20` がリアルタイムで表示されているのを確認してください。
上部メニューにある「Step Over(F10)」や「Continue(F5)」を使って、一行ずつコードの動きをコントロールできます。この感動を味わえば、もうprintデバッグには戻れなくなりますよ。

—

先輩エンジニアからのアドバイス

今回つまずきやすかったポイントを振り返ってみましょう。

  • `shared_preload_libraries` に設定したか?
  • PostgreSQLサービスを再起動したか?
  • 対象DBで `CREATE EXTENSION pldbgapi;` を実行したか?

この3ステップさえ押さえておけば、どんな環境であってもDebuggerは必ず牙を剥いてあなたに従います。

データベースの内部で何が起きているのかを可視化できるようになると、設計のスキル自体がワンランク跳ね上がります。ぜひ今日の開発環境に取り入れて、快適なデータベースライフを満喫してください!

タイトルとURLをコピーしました