描述

LISTEN 將目前的會話註冊為名為 channel 的通知通道上的監聽器。如果目前的會話已經註冊為此通知通道的監聽器，則不會執行任何動作。

每當由這個會話或連接到相同資料庫的另一個會話調用 NOTIFY channel 指令時，所有目前正在監聽該通知通道的會話都會收到通知，並且每個會話會接著通知其連接的用戶端應用程式。

可以使用 UNLISTEN 指令取消註冊特定通知通道的會話。當會話結束時，會自動清除會話的監聽註冊。

用戶端應用程式必須用來偵測通知事件的方法取決於它使用的 PostgreSQL 應用程式程式設計介面。使用 libpq 程式庫時，應用程式會將 LISTEN 發出作為普通的 SQL 指令，然後必須定期呼叫 PQnotifies 函式，以找出是否已收到任何通知事件。其他介面（例如 libpgtcl）提供更高等級的方法來處理通知事件；實際上，使用 libpgtcl 時，應用程式程式設計師甚至不應直接發出 LISTEN 或 UNLISTEN。 請參閱您正在使用的介面的文件，以取得更多詳細資訊。

參數

說明

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 陳述式。

另請參閱