支持的版本:当前 (17) / 16 / 15 / 14 / 13
开发版本:devel
不支持的版本:12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2 / 7.1

LISTEN

LISTEN — 监听通知

概要

LISTEN channel

描述

LISTEN 将当前会话注册为名为 channel 的通知通道上的监听器。如果当前会话已经注册为该通知通道的监听器,则不执行任何操作。

每当此会话或连接到同一数据库的另一个会话调用 NOTIFY channel 命令时,所有当前正在监听该通知通道的会话都会收到通知,并且每个会话反过来会通知其连接的客户端应用程序。

可以使用 UNLISTEN 命令取消注册会话对给定通知通道的监听。当会话结束时,会话的监听注册会自动清除。

客户端应用程序必须使用的方法来检测通知事件取决于它使用的 PostgreSQL 应用程序编程接口。对于 libpq 库,应用程序将 LISTEN 作为普通的 SQL 命令发出,然后必须定期调用 PQnotifies 函数以确定是否已收到任何通知事件。其他接口(例如 libpgtcl)提供了用于处理通知事件的更高级别的方法;实际上,对于 libpgtcl,应用程序程序员甚至不应直接发出 LISTENUNLISTEN。有关更多详细信息,请参阅您正在使用的接口的文档。

参数

channel

通知通道的名称(任何标识符)。

注意

LISTEN 在事务提交时生效。如果在稍后回滚的事务中执行 LISTENUNLISTEN,则正在监听的通知通道的集合保持不变。

已执行 LISTEN 的事务不能准备用于两阶段提交。

在首次设置监听会话时存在竞争条件:如果并发提交的事务正在发送通知事件,那么新监听的会话将接收到哪些事件?答案是,会话将接收到事务提交步骤中某个时刻之后提交的所有事件。但这比事务在查询中可能观察到的任何数据库状态都要稍微晚一些。这导致了以下使用 LISTEN 的规则:首先执行(并提交!)该命令,然后在新事务中检查应用程序逻辑所需的数据库状态,然后依靠通知来查找数据库状态的后续更改。最初收到的几个通知可能指的是在初始数据库检查中已经观察到的更新,但这通常是无害的。

NOTIFY 包含关于 LISTENNOTIFY 使用的更广泛的讨论。

示例

psql 配置和执行监听/通知序列

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

兼容性

SQL 标准中没有 LISTEN 语句。

提交更正

如果您发现文档中的任何内容不正确,与您对特定功能的体验不符或需要进一步说明,请使用此表单报告文档问题。