PostgreSQL 中文参考文档
🌐 英文原版 官方 ↗

LISTEN

LISTEN — 监听一个通知

Synopsis

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 语句。

另请参阅

NOTIFY, UNLISTEN, max_notify_queue_pages