LISTEN — 通知を監視する
LISTEN channel
LISTENは現在のセッションを、通知チャネルchannelのリスナとして登録します。
現在のセッションが既に指定した通知チャネルのリスナとして登録されている場合は、何も起こりません。
このセッションまたは同一データベースに接続している別のセッションによってNOTIFY が実行されると、現在その通知チャネルを監視している全てのセッションに対して通知されます。
次に、各セッションは接続中のクライアントアプリケーションにこれを通知します。
channel
UNLISTENコマンドを使って、セッションに登録された指定通知チャネルを解除できます。
また、セッションの監視登録はそのセッションが終了した時点で自動的に削除されます。
クライアントアプリケーションが通知イベントを検出する方法は、使用しているPostgreSQLアプリケーションプログラミングインタフェースに依存します。
libpqライブラリを使用するアプリケーションでは、LISTENを通常のSQLコマンドとして発行し、その後、PQnotifiesルーチンを定期的に呼び出して通知イベントが受信されたかどうかを調べる必要があります。
libpgtcl等の他のインタフェースには、通知イベントを扱うより高レベルな方法が用意されています。
実際、libpgtclを使ったアプリケーションの場合、プログラマがLISTENやUNLISTENを直接発行する必要すらありません。
詳細については、使用中のインタフェースのドキュメントを参照してください。
channel通知チャネルの名前です（任意の識別子）。
LISTENはトランザクションのコミット時に有効になります。
LISTENまたはUNLISTENがトランザクション内で実行され、それがロールバックされた場合、監視している通知チャネルの集合は変更されません。
LISTENを実行したトランザクションでは二相コミットの準備を行うことはできません。
監視するセッションを最初に設定する時に、競合状態があります。
同時にコミット中の複数のトランザクションが通知イベントを送った場合、新しく監視を始めたセッションはそのうちのどれをまさに受信するでしょうか。
答は、トランザクションのコミット段階のある瞬間の後にコミットされたすべてのイベントを受信する、です。
しかし、これは問い合わせにおいてトランザクションが気づくデータベースの状態よりもわずかに後です。
ここからLISTENを使う場合の以下のような規則が導かれます。
まずそのコマンドを実行する(そしてコミットする！)、それから新しいトランザクションでアプリケーションのロジックの必要に応じてデータベースの状態を検査する、それから通知に基づいてデータベースの状態に対するその後の変更を確認する。
最初に受信した通知のいくつかはデータベースの最初の検査ですでに確認した更新を参照しているかもしれませんが、これは普通は無害です。
NOTIFYには、LISTENおよびNOTIFYについてのより広範な説明があります。
psqlから、監視/通知処理の設定と実行を行います。
LISTEN virtual; NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448.
標準SQLにLISTENはありません。