描述

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

參見