支持的版本: 当前 (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 语句。

提交更正

如果您在文档中发现任何不正确、与您使用特定功能的体验不符或需要进一步澄清的地方,请使用此表单报告文档问题。